Zapping the Xorg server

[Wolfgang Draxinger]

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.

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

[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).