Am Montag, den 12.11.2007, 23:13 +0100 schrieb Soeren Sandmann: > Rodrigo Moya <rodrigo gnome-db org> writes: > > > On Sat, 2007-11-10 at 11:46 +0100, Sebastian Heinlein wrote: > > > Hello Rodrigo, > > > > > > As you perhaps already have read in my previous mail I am working on the > > > display configuration tool that is currently shipped in Ubuntu. > > > > > > I don't know what the plans of Fedora currently are, but would you > > > accept a configuration tool that is based on Python in > > > gnome-control-center at all? > > > > > I really don't find any problem with that, provided, of course, that the > > python part is optional, so that people don't have to have python if > > they don't want to. > > > > Apart from that, if the performance of the capplet is ok, I've got > > nothing against it > > > > Anyone has anything against it? > > Monitor configuration is an area I am planning to work on for 2.22 as > well. > > The important thing to figure out is what the user experience is going > to be like. Bryan has created some mockups here: > > http://www.gnome.org/~clarkbw/designs/monitor-resolution-settings/ We started with a similar layout for the displayconfig GTK frontend, but there are some problems with it. Here is a list of problems and question we run into: - How to make the selected monitor in the canvas widget more visible (a main problem in the Windows dialog)? MacOS has chosen to use separate configuration dialogs for each monitor that are placed on the corresponding monitor. What is really a very nice solution. - How to communicate the mode/status (enabled, extend desktop, clone desktop, disabled) of the monitor? The canvas widget cannot represent a cloned setup very well. KDE uses comboboxes. For DisplayConfigGtk we have chosen radio buttons to not hide possible states in a combobox menu. The option should be very fast to access since this is the perhaps most often used function. MacOS did a bad job here by putting the arrangement widget on the second tab of a notebook. - Support more options: enabling/disabling of devices. Additionally TV screens require to configure the format (pal/ntsc), furthermore gamma correction would also be nice to have. - How many monitors do you want to support? For displayconfig and guidance the decision was made to only support a dual head setup. Especially since all current XRandR 1.2 aware drivers don't support Xinerama anymore. So you are limited to the outputs of the same card. Furthermore how to represent unused monitors in the canvas? - How to provide a way to override the automatically detect values? Many screens cannot be detected correctly. Especially if the EDID is transferred by using ACPI, which is not support by X (yet). Allow to import the Windows drivers (.inf file)? - How to store the default layout for GDM or other users? Currently you need to write to the xorg.conf to do so. - How to workaround the virtual screen size problem without editing the xorg.conf? (The X server reserves only as much memory as needed to display the largest resolution that was known at start up time. If you want to extend your desktop you would have to make the screen larger on the run. There is a workaround to set a high virtual screen size. But the Intel drivers don't support any DRI if the (virtual) screen is larger than 2048x2048. AFAIK this will be fixed for new graphics chips only. So you would need to find a good way to communicate this to the user and make the correct decision) - Do we only want a XRandR 1.2 only applet? That will always require a second configuration applet which can handle all other cases too. > An important aspect of this is that when you plug in something that we > have seen before, that something is automatically configured to > whatever it was set to last time. My plan is to do this by computing > some sort of monitor identifier based on the EDID information and > storing that in a file on the disk. It would be nice to have a kind of gconf value that would allow the distributions to launch their tool if a new monitor was connected and the user has chosen to configure it manually. > Also part of this is changes to gtk+, metacity, and the panel to make > them react properly to monitors appearing and disappearing. I have put > up some material here: > > http://www.gnome.org/~ssp/randr > > Not particularly well-structured, but some people may find the TODO > file interesting. There are also some problems with Nautilus: It always uses the most upper left screen as the main screen. Furthermore icons are not recollected from disabled screens. > This can all be done using just RandR - no root priviledges or > xorg.conf-editing would be required. I understand that the Ubuntu tool > would also include functionality to do this. I am not opposed to > having this in the gnomecc capplet, but it needs to be done with a > separate "Advanced" button, so that Fedora and other distributions can > hook up their own xorg.conf-editing X configuration tool for it. See the bootstrapping virtual size problem above. I don't like the idea of a completely different second user interface. Furthermore I don't know why it should be advanced to configure the monitors if you use proprietary drivers, want to use monitors that are connected to separate graphics cards or set the system defaults? So you will always end up with a need for XRandR1.2 in the distro tool too. And why does every distro need its own xorg.conf editor at all? > For Fedora this tool would be system-config-display. In the longer > term, xorg.conf will hopefully become gradually more and more > irrelevant as the X server becomes more dynamically configurable. But it seems that you will always will require a kind of override infrastructure for mis-detected devices and different default layouts. Have you never thought about extending system-config-display? Perhaps we could also find a way to make the kudzu dependency optional. > As for C vs Python - it's not terribly important to me. I suspect that > writing this panel in C would be faster for me since then I wouldn't > need to create RandR python bindings, and since parsing EDID and > interacting with RandR. We already started with the python bindings. You can configure the outputs with it. What is still missing is the configuration logic that needs to be implemented above the xrandr library: arrange outputs correctly, chose the correct/best crtc for each output, recalculate the screen size and so on ... Furthermore I extended the python .inf importer that is used for hwdata. Cheers, Sebastian
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil