Re: Ubuntu X feature work for Intrepid
On Tue, Jul 15, 2008 at 07:34:56PM +0200, Brice Goglin wrote:
> Bryce Harrington wrote:
> > xorg-ctrl-alt-backspace
> > -----------------------
> > We've had bunches of requests for users to turn off this shortcut key,
> > however it's quite useful to developers. A compromise has been to
> > require holding it down for a short period of time (and/or hitting in
> > quick succession). We're tentatively planning on trying this out,
> > although I'm not 100% how to best implement it. I assume this wouldn't
> > be of interest for Debian; let me know otherwise.
> >
>
> I heard a couple users complain the same, so I think it would be good to
> have a way to switch to this behavior for these users. But of course
> some people will complain if we make it the default :)
>
> After a quick look at the code, I guess I would do:
> in xf86CommonSpecialKey(), case KEY_BackSpace, when down is set, store
> GetTimeInMillis() in a static value. If down isn't set, check that a
> time value has been stored, compare it to GetTimeInMillis() and call
> xf86ProcessActionEvent() if the timeout expired, then reset the stored
> value.
> No idea how all this is protected by locks or whatever, I have
> zero-knowledge about input event processing :)
Sounds straightforward enough. I'll look into drafting a patch after
I'm back from vacation.
> > xorg-options-editor
> > -------------------
> > In Hardy we implemented an early version of the new xrandr-enabled
> > Screen Resolution tool. While it was generally well received, it lacks
> > a lot of advanced functionality.
>
> My feeling about RandR-GUI is that many people want to write a new one
> from scratch but nobody completes it or even maintains it in the end. I
> have been very disappointed by grandr (segfaults...) and urandr
> (upstream already dead?). I'd really like to have a good one. I don't
> really care about modify driver/server options, but RandR 1.2 really
> needs a good GUI for all our users.
Yeah those are the conclusions I drew as well. I didn't want maintain
something myself, so joined efforts with RedHat on their tool. I liked
the code design, although had to patch up a handful of crash bugs, but
they accepted our patches. Federico also integrated it into SuSE. I
believe GNOME will be integrating it into gnome-control-center soon.
It's strictly a userspace app and doesn't set the driver / options, or
modify xorg.conf.
> > Much work is going into the backend python code for reading/writing
> > xorg.conf's (termed "X-Kit"), and we're looking into standardizing use
> > of it in other tools (EnvyNG, Jockey, etc.) that need to make
> > modifications to xorg.conf.
>
> What kind of xorg.conf modification does these tools need?
EnvyNG and Jockey are used for setting up the proprietary drivers.
Based on the gfx hardware they pick the driver version (in nvidia's
case) and set up any driver/server options needed to work around bugs.
Eventually (Intrepid+1 perhaps) EnvyNG and Jockey will be merged. One
is a community developed tool and the other Canonical, and they have
different use cases, but not so different that they can't be combined,
and the developers (Martin Pitt and Alberto Milone) are currently
collaborating on all the above with the goal of achieving this.
I figure the more that all the xorg.conf modifying code can be
consolodated into just a few tools / libs, the less code has to be
reviewed/updated to account for future xorg.conf changes.
> I wonder how all this would interact with the Debian installer which
> currently tries to setup an almost empty xorg.conf. Modifying an almost
> empty xorg.conf requires a very good knowledge of the server default
> behavior if we don't want to break 10 things when adding a section to
> add a single option.
It's a good point. We ran into this with displayconfig-gtk which was
fairly tightly bound to the xorg.conf structure (a fatal flaw once stuff
started disappearing). We're hoping by sticking to only adding/removing
server and driver options to avoid the breakage, but are definitely open
to suggestions.
Note that the backend xorg.conf logic is taken from KDE's
guidance-backends, which has received fairly extensive testing, but does
have known issues, and is being obsoleted in KDE4. So we figure the
backend may need to be redone at some point. jcristau mentioned an
existing python xorg.conf library, which may be a good route to go.
> I wonder if it would be easier to bypass xorg.conf completely and make
> the server query some external database at startup like input-hotplug
> does for device configuration.
Maybe. Being able to switch server/driver options on the fly would be
cool as well, but I'd expect that would require some fairly significant
rearchitecting of the whole system to achieve. I'm assuming we'll be
stuck setting these via xorg.conf for a while at least.
Bryce
Reply to: