KDrive, Xnest, Xvfb Called For Removal From X.Org

[curaga]

You're saying the moon can be fetched, it sounds like

One console keymap is 2kb, and the X internals to load it were a few hundred kb smaller than the xkb internals. I think it would be a lot of work to get the xkb option to even within 500kb of the console one, and that is still not size-competitive.


If you mean to skip console keymaps entirely, then that's additional size in the form of cxkb (btw google doesn't find it, so I couldn't measure it).

[Ibidem]

Argument by assertion isn't much fun though, so I'll say that I think it's better due to greater maintainability, not having to have two completely separate and unrelated rulesets (see, e.g. cxkb, which allows you to use XKB keymaps on the console), and due to being used by a far, far greater number of people than the alternative which was basically untested.

Xkb? The X Kitten Butcher? WHY would anyone want to use that on the console?
It seems the majority would agree with me, since Google is unaware of anyone except you who has mentioned cxkb since 2006, not to mention the homepage or source code.

So yeah, I'd much prefer to see XKB's worst flaws (mainly its size and complexity) fixed than maintain two options, only one of which sees any development or testing, when the interactions between the two are so incredibly complex as to be a significant source of problems on their own.

Why not replace the Xkb file format with the console one? It's less complex and more compact...

[daniels]

The console format isn't anywhere near expressive enough. XKB's file format is _too_ expressive and complex for sure, and indeed I'd like to shift to another format. But the console keymaps simply do not let you do quite a number of things that you need for usable keyboard handling on the desktop. Having a new file format would definitely be a win at some stage, but the stark reality is that everyone uses XKB keymaps, and there are a huge number of them that people need to be able to use their computers. Changing file format without a clean conversion is a complete non-starter.

Historically, it had too many esoteric layouts that weren't widely used, but these have almost all been shuffled out to a separate 'extra' ruleset now. Being able to turn those off at install time so they're not installed at all would be a huge boon.

The code can absolutely get a lot smaller. It's been on the backburner for a while as I've been busy with a lot of other stuff, but I'll hopefully get to it at some stage.

You're not going to get away from XKB. Yes, it has its flaws (believe me, many of them), but it's so deeply embedded in the X protocol - and Xlib API/ABI which we can never change - that you cannot have a usable desktop X11 implementation without XKB. For Wayland, my current solution has been to pare down the XKB parser to the bare essentials that both clients and server require for useful and fully-capable keyboard input and then see where that takes us in terms of file format. I've already been able to deprecate quite a few features and remove a fair bit of complexity, and I'm not done yet. But for X11, I'm afraid you're pretty much stuck with XKB as it is from now until the end of days.

[daniels]

I should also mention at this point that Debian and Ubuntu have been using cxkb by default since 2006.

[curaga]

I should also mention at this point that Debian and Ubuntu have been using cxkb by default since 2006.

http://packages.debian.org/search?se...&keywords=cxkb

Gives no results... Perhaps the package has been renamed since 2006.

You're not going to get away from XKB. Yes, it has its flaws (believe me, many of them), but it's so deeply embedded in the X protocol - and Xlib API/ABI which we can never change - that you cannot have a usable desktop X11 implementation without XKB. For Wayland, my current solution has been to pare down the XKB parser to the bare essentials that both clients and server require for useful and fully-capable keyboard input and then see where that takes us in terms of file format. I've already been able to deprecate quite a few features and remove a fair bit of complexity, and I'm not done yet. But for X11, I'm afraid you're pretty much stuck with XKB as it is from now until the end of days.

Given that we definitely have X servers running without XKB, I'm not buying that it's unseparably entrenched. I'm also not advocating forcing everyone to console maps, as they most importantly can't do many eastern languages. What I'd like is for the xkb hit to be optional, and console maps be usable when you know you don't need xkb.

[curaga]

One quick look at reducing the ruleset size

Sizes from "du -s".

3476 # before
3000 # after removing all comments
2992 # after removing empty lines and lines only consisting of space
2984 # after removing trailing space

14% off the size, and given that end-users hardly read these files (keymap editors can likely untar the source ball), perhaps these strategies could be used install time.

[daniels]

http://packages.debian.org/search?se...&keywords=cxkb

Gives no results... Perhaps the package has been renamed since 2006.

It's in the console-setup package.

[daniels]

I'm also not getting why you're not listing all of the Xorg's internal libs (libcfb libmfb libint10 etc etc), but only those. How can an user tell which can be deleted of them? ldd doesn't show anything as depending on them.

Forgot to answer this. lib[acm]fb were deleted long ago, but the short answer is that the rest are only used if required by their drivers. Got a video BIOS? Guess you'll be using int10 and vbe. Got a VGA-based driver? vgahw comes out to play. Need wrapped framebuffer access? Hello wfb. Using GLX? Then you'll probably need glx. And so on.

fbdev drivers are simple enough that you'll need fb, fbdevhw, and shadow or shadowfb and that's it. You won't be needing any modules related to userspace video BIOS access, or acceleration architectures, or userspace programming of I2C devices, or GL. So I just listed the ones that xserver-xorg-video-fbdev needed.

[curaga]

^ Thanks. That definitely should be listed somewhere in the X wiki and/or docs (preferably a compherensive list of what does each driver require ). It's the kind of hidden info that only X devs would know, at least without a lot of tedious testing one-by-one.

[daniels]

And here we agree.