Announcement

Collapse
No announcement yet.

Zaphod mode with the Open Source Driver?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • pal15
    replied
    I'll check the driver tomorrow. Do I need enter any command to make desktop to appear on second monitor?

    Leave a comment:


  • agd5f
    replied
    Make sure you are using xf86-video-ati 6.13.0 or newer. Also, kms would be a better bet than ums. The mouse issue is probably an xserver issue rather than a driver issue. You might want to try a newer xserver depending on what you currently have.

    Leave a comment:


  • pal15
    replied
    Never mind. I got it to work by editing xorg.conf file and adding following options:

    Option "ZaphodHeads" "VGA-0"
    Option "ZaphodHeads" "DVI-0"
    Option "Xinerama" "off"

    I get normal screen with desktop on the left monitor and black screen on the right. If I drag the mouse pointer from the left screen to the right it appears as X sign and would not go back to left screen. Even though the right screen is black and has no desktop I can still start programs in it from console in left screen. I can now put the script job in cron to start picture sideshow on left monitor and another picture sideshow with different set of pictures on right monitor.

    DISPLAY=:0.0 gwenview -f -s /path/dir/*
    DISPLAY=:0.1 gwenview -f -s /path/dir/*

    Is there a way to switch the mouse and keyboard between screens? Right now the mouse locks up in the right screen if moved into it.

    Also, the system would not reboot normally after 'zaphod' mode was configured. If I try to reboot monitors go black and become unresponsive.

    I would appreciate any input.

    Leave a comment:


  • pal15
    replied
    Hi All! I'm new here and I'm a newbie. I would really appreciate if someone help me out to find configuration example for zaphod mode. (Radeon 4350 HD on openSuSE 11.2)

    I need to build a machine that will have two monitors connected to it. I need to start two instances of certain program in each monitor from the script.

    For example:

    DISPLAY=:0.0 firefox
    DISPLAY=:0.1 firefox

    I understand that I need to configure zaphod mode but can't find usable example of how to do it.

    Please help!

    Leave a comment:


  • agd5f
    replied
    NP. thanks for sorting out the screen instancing issue. That was a nasty one.

    Leave a comment:


  • Chewi
    replied
    Good point about UMS and legacy configs. Looks like we've met in the middle with good results. It's working perfectly for me now. Thanks for the credit, I appreciate that.

    Leave a comment:


  • agd5f
    replied
    I've gone ahead and pushed your fix (and some of your cleanup) and now made the zaphodheads support multiple outputs per instance.

    Leave a comment:


  • agd5f
    replied
    Originally posted by Chewi View Post
    My patch doesn't change that. You're right, there is only one entity but each additional device instance creates a new "entity instance". This happens in xf86AddDevToEntity of xf86Bus.c. Each screen needs to have a pointer back to its device's entity instance, hence the xf86SetEntityInstanceForScreen function. Currently Screen1 is pointing to Screen0's instance so when it comes to match up the screen sections with the detected screens, Screen0 gets chosen in both cases.
    I think that's by design to avoid passing incompatible options to each instance of the driver, but it's been a while since I dug into that code.

    Leave a comment:


  • agd5f
    replied
    Originally posted by Chewi View Post
    I'm not sure what is driver-specific about my approach. Do you mean the "Screen 0" and "Screen 1" entries in the config? That's pretty standard, isn't it? It's in the xorg.conf man page.
    Matching the outputs based on the monitor identifier. Lots of people have legacy configs with no monitor sections or sections called "Monitor1" or whatever. The existing code works for a lot of people without requiring them to add or rename monitor sections in their config.

    Leave a comment:


  • Chewi
    replied
    Originally posted by agd5f View Post
    Actually the correct code is correct as is. There is only one entity which shared by multiple screens.
    My patch doesn't change that. You're right, there is only one entity but each additional device instance creates a new "entity instance". This happens in xf86AddDevToEntity of xf86Bus.c. Each screen needs to have a pointer back to its device's entity instance, hence the xf86SetEntityInstanceForScreen function. Currently Screen1 is pointing to Screen0's instance so when it comes to match up the screen sections with the detected screens, Screen0 gets chosen in both cases.

    I'm not sure what is driver-specific about my approach. Do you mean the "Screen 0" and "Screen 1" entries in the config? That's pretty standard, isn't it? It's in the xorg.conf man page.

    Leave a comment:

Working...
X