Announcement

Collapse
No announcement yet.

Zaphod mode with the Open Source Driver?

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

  • #21
    I just fixed it:
    http://cgit.freedesktop.org/xorg/dri...055fc0a07d8dd6

    Comment


    • #22
      That's not exactly how I was going to do it but this way, you can add more than one monitor to each head so that's great. Thanks, Alex! I'll try it tonight.

      Comment


      • #23
        Originally posted by Chewi View Post
        That's not exactly how I was going to do it but this way, you can add more than one monitor to each head so that's great. Thanks, Alex! I'll try it tonight.
        Not exactly. The option is for both instances, so for "LVDS,VGA-0", instance 0 would get LVDS and instance 1 would get VGA-0. You only get one head per instance.

        Comment


        • #24
          Originally posted by agd5f View Post
          I'm sorry to say that this didn't work for me. I'm not sure why as the log looked okay but only one of the monitors got a signal. I did try the option a few different ways but no joy.

          In any case, I'm not sure why you took the approach you did. My solution would have required fewer changes and no driver-specific option. I figured I'd better put my money where my mouth is so I resolved the aforementioned problem about Screen0 being passed twice and completed the patch. I've uploaded it to bug #24523. It assumes that commit 579cdcf9b4e38c791a497b747a055fc0a07d8dd6 has already been reverted. Please take a look. Thanks.

          Comment


          • #25
            Should be fixed now with the latest code in git.

            Comment


            • #26
              Both screens work now but the larger screen starts with 1280x720 instead of the maximum 1920x1080. Of course I can change this but this does indicate that something still isn't working properly. This doesn't happen with my patch and I highly suspect that it's because Screen0 is still being passed twice. I don't wish to be a pain but I'd rather see this done properly. Could you please comment on my patch and why you think your approach was better? While mine is not a big patch, I hadn't ever hacked X before so it took a lot of time and effort.

              Comment


              • #27
                I should add that the other monitor is only capable of 1280x1024, which is probably why it picked 1280x720.

                Comment


                • #28
                  Originally posted by Chewi View Post
                  Both screens work now but the larger screen starts with 1280x720 instead of the maximum 1920x1080. Of course I can change this but this does indicate that something still isn't working properly. This doesn't happen with my patch and I highly suspect that it's because Screen0 is still being passed twice. I don't wish to be a pain but I'd rather see this done properly. Could you please comment on my patch and why you think your approach was better? While mine is not a big patch, I hadn't ever hacked X before so it took a lot of time and effort.
                  Sorry, I haven't had a chance to review your patch yet; I just wanted to get the current code fixed. As to your patch, the screen bug is a good catch, I'll go ahead and commit that part. My remaining concerns about the patch are that it doesn't address zaphod with UMS and it requires a system specific configuration as well; granted it's the more randr like, but it still requires driver specific configuration. I'd be willing to add support both configurations (zaphodhead option and config based on monitor identifiers). I was trying to make it continue to work with old legacy configs with minimal changes.

                  Comment


                  • #29
                    Actually the correct code is correct as is. There is only one entity which shared by multiple screens.

                    Comment


                    • #30
                      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.

                      Comment

                      Working...
                      X