[PATCH 1/3] fixesproto: Add a query to get the screen layout.

Keith Packard keithp at keithp.com
Tue Jul 28 23:13:54 PDT 2009


On Tue, 2009-07-28 at 22:50 -0700, Aaron Plattner wrote:
> On Tue, Jul 28, 2009 at 10:34:52PM -0700, Keith Packard wrote:
> > * PGP Signed by an unknown key
> > 
> > On Tue, 2009-07-28 at 21:53 -0700, Aaron Plattner wrote:
> > 
> > > @@ -1,7 +1,7 @@
> > >                          The XFIXES Extension
> > > -			    Version 4.0
> > > -			 Document Revision 1
> > > -			     2006-12-14
> > > +			    Version 5.0
> > > +			 Document Revision 2
> > > +			     2009-07-27
> > 
> > Document revision should go back to 0 for the new major version.
> 
> Ah, okay, thanks.  Will do.
> 
> > >  			    Keith Packard
> > >  			  keithp at keithp.com
> > >  
> > > @@ -29,6 +29,8 @@ developers, in particular,
> > >  
> > >   +	Deron Johnson for cursor visibility
> > >  
> > > + +	Valery Moya for X screen origin queries
> > 
> > So, the first question is why this is in XFixes and not in RandR --
> > should it go there instead?
> 
> I didn't think RandR really dealt with multiple screens, other than
> allowing you to address them.  It really deals with the positions of
> outputs within a single X screen, and not with the relative positions of
> the X screens themselves.

True, but extending RandR to know about the global geometry seems like a
fairly small step to me, and makes sure that if you're looking for
global geometry information, you've only got to look in one extension.
Also, you'll want to send events once you add the ability to change
stuff, and RandR has that all wired down already.

> Perhaps when we have our grand unified RandR/Xinerama/Shatter
> implementation, it will solve all of these problems.  In the meantime, it
> doesn't really matter where this request goes, it just doesn't really seem
> like it belongs in RandR.

I dunno; it deals with similar concepts, and the benefit of putting it
in RandR is that we have one place to discuss these ideas instead of
two, making it easier to make sure things are consistent across future
changes.

> Just poking the data into dixScreenOrigins wasn't enough to change the
> cursor behavior.  I'd have to make more invasive updates into the rest of
> the server and I didn't have the time to look at what would be required.

I'd love to know what else is required -- it doesn't seem there could be
much else needed.

> Do you think it would be worth adding a request to change it, and then just
> return BadImplementation for now?

No. I'd encourage you to figure out what would be required; if it's not
a huge change, it seems like we'd avoid the whole xinerama/randr fiasco
once again (xinerama was a query-only extension as well).

> It was needed for CARD32/CARD16 in the xXFixesScreenLayoutRec structure.
> It looks like I'm going to have to create a separate redundant
> XFixesScreenLayout structure and add dumb translation code to the library,
> so I'll move this into xfixesproto.h and get rid of the Xmd.h include.

Yay! We love Xlib!

> Okay.  Thanks for your feedback.

Thanks for working on this; the less xorg.conf parsing we need, the
better :-)

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20090728/147e436a/attachment-0001.pgp 


More information about the xorg-devel mailing list