Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by daniels View Post
    In that case, I have no clue which Xfbdev you're shipping, since XKB has been mandatory for all of our servers for over four years now. If you took a four-year old version of Xorg too, then you could disable XKB from that and save 4MB. You're making a pretty pointless comparison.
    http://distro.ibiblio.org/tinycoreli...rc/Xvesa-base/
    Looks like XFree86 4.8.0.

    Comment


    • #47
      Originally posted by curaga View Post
      As shown by your own numbers, it's not only the ruleset: the size of the Xfbdev binary itself is near doubled. Is that only the xkb code? Or something else too?
      A mixture of making XKB mandatory, and other stuff we pushed from Xorg into common code.


      Originally posted by curaga View Post
      You clearly know XKB well, but it seems you haven't considered the alternative.

      Please tell me why work should be spent on making the rulesets smaller, when not using them entirely is the better option. The code path that simply uses the console keymap surely still exists?

      Shipping all console keymaps is 140kb compressed, and those are enough for most western languages. Not shipping a keymap at all is also sometimes done when there's no need for one.
      I have considered the alternative, and I still maintain that it's the better option. 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.

      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.

      Originally posted by curaga View Post
      Sorry, the amount of work in making current Xorg smaller far exceeds the cost of possible local exploits in a controlled environment. Only speaking for myself of course, but I'm also no X dev.
      No problem - it's your environment, so it's up to you to judge the importance of numerous local and remote code execution vulnerabilities.

      Comment


      • #48
        OK then. Would you say whether it would be possible to skip the 3.6mb rulesets, 400kb library and compiler entirely, without removing the X-internal xkb parts?
        I'm thinking it wouldn't be many lines of code to read the console keymap and load it into Xorg's internal xkb representation. Not that I know, merely guessing.

        That would certainly be a huge improvement, though I'd certainly like to see the 500kb of Xorg-internal xkb removable too.

        Comment


        • #49
          Not really, though it's certainly smaller to make the Xorg internals a fair bit smaller, and possible to make the ruleset very, very, very, very much smaller. To be honest that'd probably be size-competitive with parsing the console keymaps and mangling them into XKB keymaps.

          Comment


          • #50
            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).

            Comment


            • #51
              Originally posted by daniels View Post
              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...

              Comment


              • #52
                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.

                Comment


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

                  Comment


                  • #54
                    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.

                    Comment


                    • #55
                      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.

                      Comment


                      • #56
                        Originally posted by curaga View Post
                        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.

                        Comment


                        • #57
                          Originally posted by curaga View Post
                          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.

                          Comment


                          • #58
                            ^ 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.

                            Comment


                            • #59
                              And here we agree.

                              Comment

                              Working...
                              X