Hi Rémi, Thank you for the suggestions. Please see my comments in line.
Ping On Sun, Feb 14, 2010 at 3:25 PM, Rémi Cardona <[email protected]> wrote: > Le 14/02/2010 22:36, Ping Cheng a écrit : >> So, my questions are: >> >> 1. What is the proper way to retrieve TwinView's display mode and >> metamodes inside an (input) device driver? > > Short of parsing Xorg.0.log and/or xorg.conf to get to the nvidia stuff, > I don't think that's doable with TwinView (since X is totally unaware of > what the nvidia driver does, that's the whole idea behind TwinView...) Accessing Xorg.0.log could be a solution. I hoped there might be a better way to handle this case. Since TwinView setting is pretty much a static mode, we currently add TwinView related options to the driver's fdi rules for hal/udev (linuxwacom.fdi) to make the options "hot-pluggable". If there is no other way to go, we'll stay with .fdi for TwinView. >> 2. What is the proper way to retrieve RandR display mode (extended, >> clone, rotate...) and screen resolutions inside a device driver? Is >> there any difference in retrieving those info between RandR 1.2 and >> 1.3? > > IMHO, that shouldn't be done in the driver, but in an external tool. > That tool would query the server with XRandR to see which physical > displays are available and then set the tablet's properties through XI2 > properties or what not. > > Peter will probably tell you something much clever, but I can't think of > a compelling reason to do that at the driver level, when it can be done > higher up in the stack, with better potential integration with input and > display management tools in current desktop environments. It is nice to know that you don't think the driver needs to worry about this mapping feature. In fact, I've already had a bash script to handle the rotate and extended mode for RandR settings. However, I was suggested to embed the support into the driver. That's why I had this question here. With your support, I might be able to convince them that the feature is out of the driver's scope. _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
