Re: Ubuntu X feature work for Intrepid
On Wed, 2008-07-23 at 11:00 -0700, Bryce Harrington wrote: > On Tue, Jul 22, 2008 at 09:36:47AM +0200, Michel D?nzer wrote: > > On Tue, 2008-07-15 at 06:44 -0700, 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. > > > > Why not just make Option "DontZap" enabled by default? > > That was the original proposal in fact. However, a lot of people > (particularly every developer I've talked to) do rely on this shortcut > key for getting out of X, like when it locks up. Well, 'no reaction to ctrl-alt-backspace' is a pretty important part of the definition of 'lockup'. :) > They felt rather strongly that it would be seen as a major regression > to flip it on by default. Surely it's a piece of cake for those people to disable the option. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu X feature work for Intrepid
On Tue, Jul 22, 2008 at 09:36:47AM +0200, Michel D?nzer wrote: > On Tue, 2008-07-15 at 06:44 -0700, 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. > > Why not just make Option "DontZap" enabled by default? That was the original proposal in fact. However, a lot of people (particularly every developer I've talked to) do rely on this shortcut key for getting out of X, like when it locks up. They felt rather strongly that it would be seen as a major regression to flip it on by default. > P.S. Sorry for the late followup, had some e-mail trouble... No prob, I've been on vacation and internet-limited myself. Will be back at it next week. Bryce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu X feature work for Intrepid
On Tue, 2008-07-15 at 06:44 -0700, 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. Why not just make Option "DontZap" enabled by default? P.S. Sorry for the late followup, had some e-mail trouble... -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu X feature work for Intrepid
On Tue, Jul 15, 2008 at 06:44:09AM -0700, 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. Check out the openSuSE 11 X server. I'm not sure where to find the individual patches, i will ask our package magician when i get to the office. But here is a full commit log at least: http://lists.opensuse.org/opensuse-commit/2008-03/msg00899.html If i can't find an easy url for this, i will have a reason to file that bug on fd.o with the patches that i have been filing for months now... About this code: Using the PC Speaker is the only sane way to implement this, as you do not want to involve the X server in any way any more, as the user (provided he has more than one braincell) will most likely have his reasons for killing the X server. One can think of all sorts of fancy solutions for warning the user, but the main purpose of ctrl-alt-backspace then might get severely diminished, and it's then better to disable zapping altogether. So the machine beeps loudly, and when ctrl-alt-backspace is pressed again within 2s, the Xserver bails. This is off per default, unless the option ZapWarning is provided in the xorg.conf (which it is on fresh installations of opensuse). Issues: * laptops don't always come with pc speakers. Here you just don't get warned. ( * keyboard repeat can generate the second ctrl-alt-backspace after 250ms already if you do not release within that time (which is not so likely). I do not like this thing one bit, and implemented it as stepmotherly as i could. The code is of course nice and cool, and rather trivial and nonintrusive. But the beep is loud and long, so that the whole hallway will find out that you're a spanner and don't know how to use a keyboard or that this is the first time you're using an X server. I have received a lot of flack for this code, but i always happily point out the pointy haired people who wanted this in the first place (in as far as those don't already draw a lot of attention to themselves with their endless intrusive beeping now), and how this was done to end years and years of useless, endless discussions. The people complaining usually also haven't looked at their xorg.conf :) It is not upstreamed because i am very certain people don't want this. Either they want zapping disabled, or they have used a keyboard before. It does lead to a fun game you can play amongst colleagues: Nurnberger Zapwarning Shootout. With the colleagues sitting in the same office, everybody presses ctrl-alt-backspace in sequence, as fast as possible. Last one with a working X server wins, and gets a bratwurst from each of the other contestants :) Luc Verhaegen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu X feature work for Intrepid
On Tue, 2008-07-15 at 19:34 +0200, Brice Goglin wrote: > Bryce Harrington wrote: > > > 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. > I'm the author of URandR and of xorg-options-editor. URandR is not dead, I decided to rewrite it and it currently detects the screens and updates the GUI but can't apply the settings. I can work on it however (currently) I'm very busy with my other projects. One thing which I'm working on with Bryce is the Screen Resolution tool (originally created by a Fedora developer). The plan is to extend the functionality of this RandR GUI so that it can calculate and set the required virtual resolution (through X-Kit and PolicyKit) in order to set up multiple screens xinerama style when the framebuffer is not enough. I did it in Python. Bryce will deal with the C code. Here's a screencast of how it works: http://albertomilone.com/screen_resolution.ogg The code is in my PPA: https://launchpad.net/~x-kit/+archive a simple apt-get install screen-resolution-extra should install x-kit as a dependency. Then all you will have to do is type: python /usr/share/screen-resolution-extra/policyui.py 0,0:1024x768 1024,0:1280x1024 0,768:1024x768 and you will have the virtual resolution in your xorg.conf. > What kind of xorg.conf modification does these tools need? > > 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. > > 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. > > Brice > > As regards xorg-options-editor, * each graphics card represented by a Device section in the xorg.conf will appear in the treeview. If no device section is found then we can detect the available graphics cards and create empty Device sections for them. * when you click on a device in the treeview you will see all the options from its respective Device and Screen section. X-Kit makes it easy to find the relationship between Screen and Device sections. If no Screen sections are available, and an option to the Screen section must be added then a new Screen section (linked to a specific Device section) will be created. No such thing as breaking the xorg.conf should happen with X-Kit. Here's a brief screencast: http://albertomilone.com/xorgoptionsedit.ogg Regards, Alberto Milone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu X feature work for Intrepid
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 :) > 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. > One of our community members is > creating a simple python GUI applet for turning on driver and server > options, to launch from an "Advanced..." button on the Screen Resolution > tool. > > Probably easiest to explain through a screenshot: > > https://wiki.ubuntu.com/X/OptionsEditor?action=AttachFile&do=get&target=xorgconfig-07-07-2008.png > > 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? 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. 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. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
