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