Re: Where input (hotplugging) methods might go - highly speculative (was: Re: Zapping the Xorg server)
Am Fri, 27 Aug 2010 08:40:39 +1000 schrieb Peter Hutterer peter.hutte...@who-t.net: like /dev/input/mice? Kind of, but on steroids. Also in the concept I'm thinking of here, access to individual devices wasn't impossible. But you'd normally not need it. It only made sense in combination with my proposed Console Sets. Such a Console Set combines a number of connected input and output devices (also hotplugging wise). There's a default console set (of course). Withing each console set a number of VTs was available. The current kernel level multiseat support already goes into that direction, but it need a major cleanup. we've used that for years, before X itself had hotplugging support. Turns out that for plenty of use-cases having the devices available in the X server is quite handy. I know. For example I don't like the touchpand in my notebook, I prefer the trackpad. You figure the rest. you're still free to disable hotplugging and use the mouse and keyboard drivers, thus not having the X server see any new devices and just handle the kernel accumulated ones. That, and improve the input handling of the kernel, yes. That's inevitable anyway if one thinks of how multiseat systems are done right now *shudders*. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On 17:04 Thu 26 Aug , Glynn Clements wrote: Wolfgang Draxinger wrote: Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. Because it's ridiculously difficult. Something like Xpra code.google.com/p/partiwm/wiki/xpra? -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpTXK774pXhN.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Wed, Aug 25, 2010 at 5:45 PM, Wolfgang Draxinger wdraxinger.maill...@draxit.de wrote: On Thu, 26 Aug 2010 08:44:46 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: Also, assuming that if we ditched input features somehow Gallium or other graphics parts would be finished sooner is a logical fallacy. I'm not talking about sooner. It's more like running into one direction, then realizing you've to go back, because things took a different direction. What I see on the horizon, I may be utterly wrong and misguided, is a concept I'd call console sets. Instead of somehow managing a number of input/output devices by means of helper deamons (consolekit *york*), which systems like X.org (but also others) have to use individually, it makes much more sense, to aggregate sets of devices into a Console Set, where each of them has it's own number of VTs. Think of multihead on the VT level, which is possible already, but through a rather clumsy interface. And Xorg, but also other things, then would simply run on top of that. Looking at Gallium and other things, to me it looks like the X server will transistion from a graphics driver/subsystem into something simpler, namely a network transparent graphics interface and windowing system. Maybe in the end we'll end up with some sort of Gallium kdrive on a Console Set. Abstracting away input hotplugging into the kernel, so that more programs can easily take advantage from it. Peter's been working solely on input handling and the XInput 2 stuff since he got started. If you want more work put into Gallium, you should find people like Marek, Luca, or me, that currently work on Gallium unpaid in our spare time, and pay us to focus on it. (You also might have to convince us to take the money -- I for one have decided to keep my current lower-stress local job rather than work all the time on graphics, and I bet the other amateurs are the same way.) ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
Donnie Berkholz wrote: Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. Because it's ridiculously difficult. Something like Xpra code.google.com/p/partiwm/wiki/xpra? That's essentially Xvnc except that it uses Composite to do it window-by-window rather than for the whole screen. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
Am Fri, 27 Aug 2010 08:50:33 -0700 schrieb Corbin Simpson mostawesomed...@gmail.com: Peter's been working solely on input handling and the XInput 2 stuff since he got started. If you want more work put into Gallium, you should find people like Marek, Luca, or me, that currently work on Gallium unpaid in our spare time, and pay us to focus on it. Take as much time as you need. I'm neither pushing nor forcing. Actually I think you guys make huge progress, and do a very good job. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
Wolfgang Draxinger wdraxinger.maill...@draxit.de writes: I'm one of those who's work would be severely disrupted by a hardwired CTRL-ALT-Backspace Zap. CTRL-ALT-Backspace is hardwired in my fingers from nearly 30 years of editing using Emacs and kin. Just curious here, and don't want to start a editor war. But please tell a hardcore Vim user: What hotkey/command of Emacs collides this with? Bindings like Control-Meta-foo are generally used in Emacs for navigating by and operating on s-expressions (an s-expression is basically a word or parenthetically-balanced text); so C-M-f goes forward by 1 sexp, C-M-b goes backward, C-M-u goes up, etc. Following this pattern, C-M-backspace _should be_ delete previous sexp. Only instead, it kills your X server... :( This hit me regularly because I'd get very very used to the hold down control and meta with one hand, and hit f/b/u/etc with the other to operate on sexps pattern, and then, naturally, hit the backspace key. I would also occasionally hit it simply by accident, I think because I'd try to hit M-backspace (delete previous word), but would be slightly too slow in releasing the control-key from a previous command... man, _that_ was annoying!! -Miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin] ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Thu, 26 Aug 2010 16:25:04 +0900 Miles Bader mi...@gnu.org wrote: (...) Only instead, it kills your X server... :( Ouch... Well, using Vim (and I preferably in uxterm) one is kind of protected from loosing changes by putting things into a screen session (but of course all the other non-text-console programs will loose their stuff). Seeing a lot of Emacs users using XEmacs or GNU Emacs in X mode that obviously won't work. Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. And make this proxy de-/attachable. So far I emulated such using Xvnc, but that means no HW acceleration, no indirect GLX and such things. Of course such a thing boils down to implementing an almost fully featured X server, so if I were to implement such a thing, I'd probably start of kdrive/Xephyr. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Thu, Aug 26, 2010 at 5:16 AM, Wolfgang Draxinger wdraxinger.maill...@draxit.de wrote: On Thu, 26 Aug 2010 16:25:04 +0900 Miles Bader mi...@gnu.org wrote: (...) Only instead, it kills your X server... :( Ouch... Well, using Vim (and I preferably in uxterm) one is kind of protected from loosing changes by putting things into a screen session (but of course all the other non-text-console programs will loose their stuff). Seeing a lot of Emacs users using XEmacs or GNU Emacs in X mode that obviously won't work. Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. And make this proxy de-/attachable. So far I emulated such using Xvnc, but that means no HW acceleration, no indirect GLX and such things. Of course such a thing boils down to implementing an almost fully featured X server, so if I were to implement such a thing, I'd probably start of kdrive/Xephyr. There was a GSOC project to implement screen-like functionality for X a few years ago, but it ended up being a lot more complex than anyone thought at the beginning and thus was never completed. Alex ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Thu, Aug 26, 2010 at 04:50:18PM +0200, ext Alex Deucher wrote: On Thu, Aug 26, 2010 at 5:16 AM, Wolfgang Draxinger wdraxinger.maill...@draxit.de wrote: On Thu, 26 Aug 2010 16:25:04 +0900 Miles Bader mi...@gnu.org wrote: (...) Only instead, it kills your X server... :( Ouch... Well, using Vim (and I preferably in uxterm) one is kind of protected from loosing changes by putting things into a screen session (but of course all the other non-text-console programs will loose their stuff). Seeing a lot of Emacs users using XEmacs or GNU Emacs in X mode that obviously won't work. Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. And make this proxy de-/attachable. So far I emulated such using Xvnc, but that means no HW acceleration, no indirect GLX and such things. Of course such a thing boils down to implementing an almost fully featured X server, so if I were to implement such a thing, I'd probably start of kdrive/Xephyr. There was a GSOC project to implement screen-like functionality for X a few years ago, but it ended up being a lot more complex than anyone thought at the beginning and thus was never completed. xpra and xmove also are not that far from this idea. Tiago ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
Wolfgang Draxinger wrote: Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. Because it's ridiculously difficult. And make this proxy de-/attachable. So far I emulated such using Xvnc, but that means no HW acceleration, no indirect GLX and such things. Of course such a thing boils down to implementing an almost fully featured X server, so if I were to implement such a thing, I'd probably start of kdrive/Xephyr. It's actually harder than a fully-featured X server. A normal X server knows what hardware it's dealing with, and the hardware doesn't change while it's running. A proxy has to deal with the case where it disconnects from one server and connects to one with completely different parameters. -- Glynn Clements gl...@gclements.plus.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Where input (hotplugging) methods might go - highly speculative (was: Re: Zapping the Xorg server)
On Thu, 26 Aug 2010 12:20:31 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: uhm. hotplugging works in that the X server receives an event when a device was added by the kernel. Then it opens the device file. See, that's exactly what I meant: There's extra work to be done by X, or any other program dealing with complex input. Why not place the abstraction in the operating system core (i.e. kernel for monolithic, or system daemons for microkernel). Have a special devices /dev/input/consolesetn/allinput (or whatever you're going to name it) which always refers to the abstract input device of current VT. And all the input devices events are received through this single channel. Of course the protocol used needs to be a little bit more sophisticated than evdev. And all the devices configuration, keycode - symbol mapping, and all that stuff, it's all done by the kernel. Right now there are two distinct input systems around: The text console. And X input. Both need to be configured individually. Yes, I am aware, that due to Xkb you've got an additional layer above the input. Wrangling all the different devices, their nodes and configuration by a plethora of deamons and more or less complicated communication protocols looks somewhat, err, insane, if you need quite some infrastructure working to do things, that by themself should be part of the basic infrastructure. Ok, without much ado: I loathe ConsoleKit and PolicyKit (and Network Manager and a few other things which have some nice polish on the outside but are unnerving if you've to tame them, your needs deviating from the usual, in this case how permissions on user's stations are set). Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Where input (hotplugging) methods might go - highly speculative (was: Re: Zapping the Xorg server)
On Thu, Aug 26, 2010 at 06:59:48PM +0200, Wolfgang Draxinger wrote: On Thu, 26 Aug 2010 12:20:31 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: uhm. hotplugging works in that the X server receives an event when a device was added by the kernel. Then it opens the device file. See, that's exactly what I meant: There's extra work to be done by X, or any other program dealing with complex input. Why not place the abstraction in the operating system core (i.e. kernel for monolithic, or system daemons for microkernel). Have a special devices /dev/input/consolesetn/allinput (or whatever you're going to name it) which always refers to the abstract input device of current VT. like /dev/input/mice? we've used that for years, before X itself had hotplugging support. Turns out that for plenty of use-cases having the devices available in the X server is quite handy. you're still free to disable hotplugging and use the mouse and keyboard drivers, thus not having the X server see any new devices and just handle the kernel accumulated ones. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Tue, 24 Aug 2010 20:19:05 +0200 Julien Cristau jcris...@debian.org wrote: This is not true. The sequence was removed from the default xkb map, and can be turned back on with the appropriate xkb option, either in xorg.conf or your desktop or your session startup scripts. Well, this is a Xkb option, and if I'm not entirely mistaken, can be enabled as well as disabled by setxkbmap, whereas the old server zap did work independently from that, no matter what was set later on. No related xorg.conf option has been removed. I beg to differ: ServerFlags Option DontZap off is no longer interpreted (on my system). I have to use XkbOption terminate:ctrl_alt_bksp to make it work. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Tue, 24 Aug 2010 19:05:42 +0100
Andrew Clayton and...@digital-domain.net wrote:
Don't worry. It's still there.
In some form, yes. However it can be disabled by
setxkbmap -option
Now there are situations in which you don't want users being able to
disable the Zap, but also don't want the SysRq to be there. And and I
don't want to refrain to writing a deamon reading on
/dev/input/${KEYBOARD_INPUT} to kill the current VT X server when
the hotkey comes by.
setxkbmap -option terminate:ctrl_alt_bksp
I'm aware of that, see my original post. The new method mimics the old
behaviour, it doesn't fully substitute it.
Changes like in the default behaviour like with the Zap
Sequence should be well documented. Well means: Don't silently
introduce (kinda like when the X server would accept being started w/o
input devices and input device autodiscovery disabled, leaving you with
an unresponsive console). Some people got pretty pi^ with some
of the changes recent releases brought with them. And frankly: To some
degree I have to agree.
Wolfgang
^: If you understand german: http://blog.fefe.de/?ts=b53326b6
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Tue, 24 Aug 2010 13:33:03 -0400 (EDT) Patrick O'Donnell p...@ascent.com wrote: I'm one of those who's work would be severely disrupted by a hardwired CTRL-ALT-Backspace Zap. CTRL-ALT-Backspace is hardwired in my fingers from nearly 30 years of editing using Emacs and kin. Just curious here, and don't want to start a editor war. But please tell a hardcore Vim user: What hotkey/command of Emacs collides this with? A quick google on the topic just brought up numerous forum/maillist posts of people angry with the new default behaviour on the Zap hotkey. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Wed, 25 Aug 2010 09:07:16 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: re:xmodmap, the following may be interesting reading http://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html Educational indeed. However I hate relying on desktop environments and their developers. What if I don't use one of the big two (Gnome, KDE)? What if I'm using XMonad and must do everything using CLI tools called by scripts? (BTW: The CLI tools tend to be more reliable than their GUI counterparts, e.g. I use xrandr exclusively because any GUI to XRandR has issues in some way, and I've become tired of bug reorting). Also it's again a prime example of fancy features given higher priority than the really important stuff. The guy who actually has multiple keyboards all with different layouts connected to the same X session please stand up. Yes, it's a nice to have, but I think there are other things, that really should be brought forward. Like Gallium and other parts of a unified graphics system for Linux. Or working in the stability and code quality of X.org as a whole. re:zapping, the XKB option was _added_ in response to the initial default of DontZap on (which now defaults to off again, like it always has) http://who-t.blogspot.com/2009/04/zapping-server.html Allright. But then I propose, that there should be some way to configure a Zap that can't be overridden by the user. Either way, it's not going to be removed by some smartass. We'll see about that. The problem here (and with some of other more or less recent developments) is/was, that I tend to have a pretty good gut feeling about what's going to happen. So let's cross fingers, that I'm wrong this time around. If I had to decide anything about this, I'd put development of features to a full stop and focus on getting rid of bugs and improve stability. I mean, X must not crash if a client does something nasty. Yet it happens quite often to me, that X crashes due to a client's action. For example if I install MinGW tools with(in) Wine, the mapping of one of the summary window crashes X if there's no reparenting WM (I figured this out only last week, so I didn't file a bug report yet, because I don't know yet, what's actually going on). Stability and code quality, that's what IMHO X.org should focus on. All the rest, it works good enough to be way ahead of the competition, and it's mainly the DE's developers who must get their act together. IMHO KDE4 is an Epic Fail, and Gnome, well, the only good thing about is GLib and GTK, the rest su*** - I liked KDE3 though and had so much hope for KDE4 and got hugely disappointed. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Delayed reply-CCs (was: Zapping the Xorg server)
Sorry guys, I just took notice, that my replies missed the CC to the maillist (my failure, I messed up my MUAs configuration). So those who now get duplicates, due to the directly addressed replies, and now the CC, take my apologies. But I prefer to CCs my answers here for the discussion being documented. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
please tell a hardcore Vim user: What hotkey/command of Emacs collides See: http://www.foldr.org/~michaelw/log/programming/lisp/dontzap-emacs Pat --- On Wed, Aug 25, 2010 at 12:14 PM, Wolfgang Draxinger wdraxinger.maill...@draxit.de wrote: On Tue, 24 Aug 2010 13:33:03 -0400 (EDT) Patrick O'Donnell p...@ascent.com wrote: I'm one of those who's work would be severely disrupted by a hardwired CTRL-ALT-Backspace Zap. CTRL-ALT-Backspace is hardwired in my fingers from nearly 30 years of editing using Emacs and kin. Just curious here, and don't want to start a editor war. But please tell a hardcore Vim user: What hotkey/command of Emacs collides this with? A quick google on the topic just brought up numerous forum/maillist posts of people angry with the new default behaviour on the Zap hotkey. See: http://www.foldr.org/~michaelw/log/programming/lisp/dontzap-emacs Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: pekan...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On 2010/08/25 19:13 (GMT+0200) Wolfgang Draxinger composed: On Tue, 24 Aug 2010 20:19:05 +0200 No related xorg.conf option has been removed. I beg to differ: ServerFlags Option DontZap off is no longer interpreted (on my system). Did you try it correctly quoted? Section ServerFlags Option ZapWarningOff Option DontZap Off ... Works in openSUSE 11.3's 1.8whatever. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Wed, Aug 25, 2010 at 07:13:39PM +0200, Wolfgang Draxinger wrote: On Tue, 24 Aug 2010 20:19:05 +0200 Julien Cristau jcris...@debian.org wrote: This is not true. The sequence was removed from the default xkb map, and can be turned back on with the appropriate xkb option, either in xorg.conf or your desktop or your session startup scripts. Well, this is a Xkb option, and if I'm not entirely mistaken, can be enabled as well as disabled by setxkbmap, whereas the old server zap did work independently from that, no matter what was set later on. the keyboard driver had special key handling, including for zapping the server. this was performed by the driver though now the driver uses XKB actions as well. evdev always relied solely on the Terminate_Server XKB action. No related xorg.conf option has been removed. I beg to differ: ServerFlags Option DontZap off is no longer interpreted (on my system). I have to use XkbOption terminate:ctrl_alt_bksp to make it work. from xorg.conf(5): Option DontZap boolean This disallows the use of the Terminate_Server XKB action (usu‐ ally on Ctrl+Alt+Backspace, depending on XKB options). This action is normally used to terminate the Xorg server. When this option is enabled, the action has no effect. Default: off. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Wed, Aug 25, 2010 at 07:14:15PM +0200, Wolfgang Draxinger wrote: On Wed, 25 Aug 2010 09:07:16 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: re:xmodmap, the following may be interesting reading http://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html Educational indeed. However I hate relying on desktop environments and their developers. What if I don't use one of the big two (Gnome, KDE)? What if I'm using XMonad and must do everything using CLI tools called by scripts? (BTW: The CLI tools tend to be more reliable than their GUI counterparts, e.g. I use xrandr exclusively because any GUI to XRandR has issues in some way, and I've become tired of bug reorting). Then you get to either fix the scripts or fix your DE. No-one really cares _what_ desktop environment you're running and one is as good as the other. The one developers are running themselves naturally get more attention. If you chose to use a different one, then you need to spend the time fixing it up to move with the times. Also it's again a prime example of fancy features given higher priority than the really important stuff. The guy who actually has multiple keyboards all with different layouts connected to the same X session please stand up. Yes, it's a nice to have, but I think there are other things, that really should be brought forward. Like Gallium and other parts of a unified graphics system for Linux. And you are free to motivate people to work on the features you really want instead of the features they want. I for one am hesitant to tell people what they need to do in their spare time and even less so for people who employed by a different employer than me. Also, assuming that if we ditched input features somehow Gallium or other graphics parts would be finished sooner is a logical fallacy. Or working in the stability and code quality of X.org as a whole. re:zapping, the XKB option was _added_ in response to the initial default of DontZap on (which now defaults to off again, like it always has) http://who-t.blogspot.com/2009/04/zapping-server.html Allright. But then I propose, that there should be some way to configure a Zap that can't be overridden by the user. Now we're talking: that is actually an interesting request, though I do have to ask: why? Either way, it's not going to be removed by some smartass. We'll see about that. The problem here (and with some of other more or less recent developments) is/was, that I tend to have a pretty good gut feeling about what's going to happen. So let's cross fingers, that I'm wrong this time around. If I had to decide anything about this, I'd put development of features to a full stop and focus on getting rid of bugs and improve stability. you are welcome to help of course. submitting patches is the most direct way of helping out, but testing, reporting bugs, and helping with documentation (both in man pages and on the wiki) is equally important. http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Thu, 26 Aug 2010 08:44:46 +1000
Peter Hutterer peter.hutte...@who-t.net wrote:
Then you get to either fix the scripts or fix your DE. No-one really
cares _what_ desktop environment you're running and one is as good as
the other. The one developers are running themselves naturally get
more attention. If you chose to use a different one, then you need to
spend the time fixing it up to move with the times.
I can fix my scripts, yes. But I can't fix all the scripts of the
potentially 3000+ users, here on the systems I manage. Even if only 5%
used something exotic, that would be still 150 users, some of them
very stubborn, carrying their precious .xinitrc and FVWM configurations
for literally decades. Now I'm the complete opposite of stubborn, I
like to experiment and try out new things, for me the problem is, that
there's still a lot of outdated documentation around and new revisions
not clearly marking deprecated stuff as such. And let's not forget the
rather arbitrary naming scheme of vital tools:
xmodmap, setxkbmap, xinput...
Now I'm not intimately familiar with the new relationship between core
keyboard and Xkb and the following probably extremely naive: The way it
looks to me though, it should be possible, to map all the physical
keyboard devices to an abstract keyboard device being core and
interacting with xmodmap (the way: Xkb_keycode - Xkb_keysym -
abstract_keysym - core_keysym + core_keycode (arbitrary, may be pc105
keycode)). Same goes for connected pointers. All the advanced stuff
(Xkb, XInput) and configuration on individual devices would then map
into abstract space.
Also, assuming that if we ditched input features somehow Gallium or
other graphics parts would be finished sooner is a logical fallacy.
I'm not talking about sooner. It's more like running into one
direction, then realizing you've to go back, because things took a
different direction.
The whole input hotplugging. I never liked the way(s) it was done in
X.org. The same way I disliked HAL^1 and the very first iteration of
udev^2.
What I see on the horizon, I may be utterly wrong and misguided, is a
concept I'd call console sets. Instead of somehow managing a number
of input/output devices by means of helper deamons (consolekit *york*),
which systems like X.org (but also others) have to use individually, it
makes much more sense, to aggregate sets of devices into a Console
Set, where each of them has it's own number of VTs. Think of multihead
on the VT level, which is possible already, but through a rather clumsy
interface.
And Xorg, but also other things, then would simply run on top of that.
Looking at Gallium and other things, to me it looks like the X server
will transistion from a graphics driver/subsystem into something
simpler, namely a network transparent graphics interface and windowing
system. Maybe in the end we'll end up with some sort of Gallium kdrive
on a Console Set.
Abstracting away input hotplugging into the kernel, so that more
programs can easily take advantage from it.
Well, that's future talk.
But so far I've seen at least 2 completely different takes on
hotplugging. I really like the most recent attempt, using udev and input
classes much more. And without trying to say told you so honestly,
when I saw the mess of HAL based hotplugging, I always thought:
Couldn't this be done better and simpler, something based on simple
configuration rules? I had no clear idea of how to do it, so I kept my
mouth shut. But the new system pretty much is a solid implementation of
my then very vague ideas.
Now we're talking: that is actually an interesting request, though I
do have to ask: why?
I this particular case: I'm system administrator at my university's
student computer lab. Some students tend to lock their sessions,
(override-)configuring {x,gnome,k}screensaver not to allow opening a
new session AND in the background start lengthy computational jobs.
This is strictly disallowed by us. We got a job queue engine for that.
People are explicitly allowed to zap locked sessions, if it's
obvious, the user who used the machine last went for lunch or came in
in the morning, starting his job, coming back sometime in the evening.
Or people just forget to log out.
But it's the hogs I'm worried about. And since you can disable the Xkb
option for terminate, I'm pretty sure, those would eventually find it.
Allowing ordinary users to zap is allowed for two reasons: There's not
always an operator on shift who could sudo-pkill the session, and it's
also meant as some sort of education: Don't be a hog, and don't leave
your station with unsaved data.
That's also the reason we don't want to do it via SysRq. It's too
close to SysRq+O or SysRq+I; even if the dangerous methods can be
disabled we prefer to disable it completely.
Wolfgang
[1]: Whoever thought, building some XML monster to replace what, a task
the kernel already does for you and which can be accessed by simple
open/read/write through sysfs, must have
Re: Zapping the Xorg server
On Thu, Aug 26, 2010 at 02:45:51AM +0200, Wolfgang Draxinger wrote: On Thu, 26 Aug 2010 08:44:46 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: Then you get to either fix the scripts or fix your DE. No-one really cares _what_ desktop environment you're running and one is as good as the other. The one developers are running themselves naturally get more attention. If you chose to use a different one, then you need to spend the time fixing it up to move with the times. I can fix my scripts, yes. But I can't fix all the scripts of the potentially 3000+ users, here on the systems I manage. Even if only 5% used something exotic, that would be still 150 users, some of them very stubborn, carrying their precious .xinitrc and FVWM configurations for literally decades. Now I'm the complete opposite of stubborn, I like to experiment and try out new things, for me the problem is, that there's still a lot of outdated documentation around and new revisions not clearly marking deprecated stuff as such. And let's not forget the rather arbitrary naming scheme of vital tools: xmodmap, setxkbmap, xinput... Now I'm not intimately familiar with the new relationship between core keyboard and Xkb and the following probably extremely naive: The way it looks to me though, it should be possible, to map all the physical keyboard devices to an abstract keyboard device being core and interacting with xmodmap (the way: Xkb_keycode - Xkb_keysym - abstract_keysym - core_keysym + core_keycode (arbitrary, may be pc105 keycode)). Same goes for connected pointers. All the advanced stuff (Xkb, XInput) and configuration on individual devices would then map into abstract space. this is exactly how it works internally. the master pointer and master keyboard provide these abstract device, with the physical devices being attached to them. we've put some effort in to make sure that configuration on the master devices will be pushed back to the actual devices. hence why xmodmap and other commands still work. However, any of these commands is a once-off attempt only, once you unplug any device, suspend/resume or do per-device configuration it doesn't scale anymore. for good configuration, you need something monitoring for device hotplug events and re-applying the configuration. as for outdated documentation: the best way is to bring this to attention of a developer. Also, assuming that if we ditched input features somehow Gallium or other graphics parts would be finished sooner is a logical fallacy. I'm not talking about sooner. It's more like running into one direction, then realizing you've to go back, because things took a different direction. The whole input hotplugging. I never liked the way(s) it was done in X.org. The same way I disliked HAL^1 and the very first iteration of udev^2. What I see on the horizon, I may be utterly wrong and misguided, is a concept I'd call console sets. Instead of somehow managing a number of input/output devices by means of helper deamons (consolekit *york*), which systems like X.org (but also others) have to use individually, it makes much more sense, to aggregate sets of devices into a Console Set, where each of them has it's own number of VTs. Think of multihead on the VT level, which is possible already, but through a rather clumsy interface. And Xorg, but also other things, then would simply run on top of that. Looking at Gallium and other things, to me it looks like the X server will transistion from a graphics driver/subsystem into something simpler, namely a network transparent graphics interface and windowing system. Maybe in the end we'll end up with some sort of Gallium kdrive on a Console Set. Abstracting away input hotplugging into the kernel, so that more programs can easily take advantage from it. Well, that's future talk. uhm. hotplugging works in that the X server receives an event when a device was added by the kernel. Then it opens the device file. Likewise with removal. No flying cars required at all. full seat configuration through ConsoleKit isn't quite there yet, afaict. But so far I've seen at least 2 completely different takes on hotplugging. I really like the most recent attempt, using udev and input classes much more. And without trying to say told you so honestly, when I saw the mess of HAL based hotplugging, I always thought: Couldn't this be done better and simpler, something based on simple configuration rules? I had no clear idea of how to do it, so I kept my mouth shut. But the new system pretty much is a solid implementation of my then very vague ideas. the HAL mess showed us how configuration should be done and most of the InputClass design is heavily influenced by the .fdi files. I for one am glad that we had this exposure. It wasn't good, but we did gain some valuable knowledge. anyway, udev and HAL are virtually identical in their approach and you'll find that Debian and Ubuntu ship
Re: Zapping the Xorg server
Peter Hutterer peter.hutte...@who-t.net writes:
On Thu, Aug 26, 2010 at 02:45:51AM +0200, Wolfgang Draxinger wrote:
[...]
I this particular case: I'm system administrator at my university's
student computer lab. Some students tend to lock their sessions,
(override-)configuring {x,gnome,k}screensaver not to allow opening a
new session AND in the background start lengthy computational jobs.
This is strictly disallowed by us. We got a job queue engine for that.
People are explicitly allowed to zap locked sessions, if it's
obvious, the user who used the machine last went for lunch or came in
in the morning, starting his job, coming back sometime in the evening.
Or people just forget to log out.
But it's the hogs I'm worried about. And since you can disable the Xkb
option for terminate, I'm pretty sure, those would eventually find it.
Allowing ordinary users to zap is allowed for two reasons: There's not
always an operator on shift who could sudo-pkill the session, and it's
also meant as some sort of education: Don't be a hog, and don't leave
your station with unsaved data.
if you rely on users to zap the session for CPU hogs, then I think the real
problem is elsewhere, but not in whether the user can change the XKB map or
not.
In general I agree, but I can see how it can be a useful and educational
strategy in this case. I might argue that there are better ways, but I
won't argue that this choice is unreasonable.
Of course, that implies that Wolfgang's case is truly a special case and
should not dictate general X behaviour. Probably the correct solution
to support this behaviour is that the university should use its own
version of the keyboard driver (evdev, I assume), which recognizes
ctl+alt+backspace and zaps the server.
eirik
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Zapping the Xorg server
Hi, as you might know, Zapping the Xorg server by means of CTRL+ALT+BACKSPACE has been first disabled by default, and later on the xorg.conf option went away, too. It is still possible to setxkbmap -option terminate:ctrl_alt_bks somewhere in the startup/init scripts to reenable, but I wonder when some smartass will vote to get it removed, too. Not to forget, that it doesn't get along well with xmodmap. As a substitute the Magic SysRq ALT+SYSRQ+K has been suggested. Now whoever did suggest this, please stand up, err press ALT+SYSRQ+O, or ALT+SYSRQ+I now! (at least on my keyboard O and I are adjacent to K). Well, it is possible to configure SysRq so that those dangerous actions are not allowed, but some people (like me), want them to be enabled (for some reason), yet still be able to kill the X server without endangering the rest of the system, by accidently hitting the wrong key. And IMHO on some systems it's desireable to disable SysRq, while still being able to kill the X server. Also on some keyboards there simply is no (usable) Print/SysRq key (take my laptop for example, where I need to hold Fn to access SysRq, which however also turns some of the letter keys into Numpad-Keys, yes yes, I know: by the right sequence of 'Hold ALT','Hold Fn','Press SysRq','Release SysRq','Release Fn','Press Command Key' it can be done, too, but it's just annoying and it might not work for other people). CTRL, ALT and BACKSPACE however are present and behave the same on every keyboard (I know of, which are plenty). So, could we please bring back the static configuration for zapping the X server by builtin method. If someone still insists on enabling and using the SAK SysRq, he still can do so, that's not mutually exclusive. Frankly, I don't see any sane reason, why it was removed in the first place. Disabling it by default, okay I can live with that. But taking away the option alltogether: Not good. Wolfgang ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
Date: Tue, 24 Aug 2010 18:08:55 +0200 From: Wolfgang Draxinger wdraxinger.maill...@draxit.de ... CTRL, ALT and BACKSPACE however are present and behave the same on every keyboard (I know of, which are plenty). So, could we please bring back the static configuration for zapping the X server by builtin method. If someone still insists on enabling and using the SAK SysRq, he still can do so, that's not mutually exclusive. Frankly, I don't see any sane reason, why it was removed in the first place. Disabling it by default, okay I can live with that. But taking away the option alltogether: Not good. I'm one of those who's work would be severely disrupted by a hardwired CTRL-ALT-Backspace Zap. CTRL-ALT-Backspace is hardwired in my fingers from nearly 30 years of editing using Emacs and kin. However, I must agree that taking away the /option/ of turning that on for those who want it is double plus ungood. - Pat ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Tue, Aug 24, 2010 at 18:08:55 +0200, Wolfgang Draxinger wrote: Hi, as you might know, Zapping the Xorg server by means of CTRL+ALT+BACKSPACE has been first disabled by default, and later on the xorg.conf option went away, too. This is not true. The sequence was removed from the default xkb map, and can be turned back on with the appropriate xkb option, either in xorg.conf or your desktop or your session startup scripts. No related xorg.conf option has been removed. Cheers, Julien ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Tue, 24 Aug 2010 18:08:55 +0200, Wolfgang Draxinger wrote: Frankly, I don't see any sane reason, why it was removed in the first place. Disabling it by default, okay I can live with that. But taking away the option alltogether: Not good. Don't worry. It's still there. If your using gnome, you can enable it in the keyboard preferences; layouts - options - key sequence to kill the X server Or setxkbmap -option terminate:ctrl_alt_bksp Andrew ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Zapping the Xorg server
On Tue, Aug 24, 2010 at 06:08:55PM +0200, Wolfgang Draxinger wrote: as you might know, Zapping the Xorg server by means of CTRL+ALT+BACKSPACE has been first disabled by default, and later on the xorg.conf option went away, too. It is still possible to setxkbmap -option terminate:ctrl_alt_bks somewhere in the startup/init scripts to reenable, but I wonder when some smartass will vote to get it removed, too. Not to forget, that it doesn't get along well with xmodmap. re:xmodmap, the following may be interesting reading http://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html re:zapping, the XKB option was _added_ in response to the initial default of DontZap on (which now defaults to off again, like it always has) http://who-t.blogspot.com/2009/04/zapping-server.html Either way, it's not going to be removed by some smartass. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
