Zapping the Xorg server

[Peter Hutterer]

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.hutterer at 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 a modified 1.7 server that uses udev quite
similarly to HAL. The InputClass configuration was added because we knew
that HAL configuration was not the way to go and we needed something better.
Until someone (in this case Dan) stepped up and wrote the code, nothing
happened though.

> > 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."
 
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.

> [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 serious mental problems. Alas,
> Xorg did the IMHO right thing and left HAL to die. bravo!

as usual, things aren't quite as black and white and the whole situation is
a tad more nuanced than just that.

Cheers,
  Peter

> [2]: e.g. udev now became what I proposed back when devfs was
> dropped; at that time I suggested using a special kind of tmpfs, which
> is automatically populated with kernel named device nodes. I also
> mentioned, that renaming kernel names by udev is a bad idea. When I
> first mentioned this, my arguments hit deaf ears. Now, some years later,
> both things happend: Kernel name renaming caused problems and were
> removed of udev, and devtmpfs implements exactly the scheme I proposed
> back then (I'm still waiting for my suggested file descriptors
> for anonymous memory to become mainline though, but due to the broad
> availability of 64 bit address space they've become rather
> uninteresting).