OpenBSD Journal

X.Org X11R7.x in OpenBSD

Contributed by mbalmer on from the x10-x11-x12 dept.

Matthieu Herrb, matthieu@, reports on changes made to X.Org which will affect the way X11 is built on OpenBSD:

The new X.Org release will be imported in OpenBSD shortly after OpenBSD 4.0 release, to be ready for OpenBSD 4.1. As people may already know, one of the main change in X.Org 7.x is a new modular build system, using GNU autotools. The X.Org source tree has been split into more than three hundred (http://wiki.x.org/wiki/ModuleComponentList) more or less independdant packages.

The existing X11 source tree, built using the imake build system, was considered as a big monolithic thing in which most developers found themselves uncomfortable. The need for global releases, updating all drivers at once every six month or so doesn't really fit the market of graphics cards that can produce new models more often than that timeframe.

Based on the experiences of other software projects, it was decided to switch to a more modular organization of the project, with more or less independent components ( http://people.freedesktop.org/~daniels/exdctalk/ ). This new organization will allow drivers maintainers (or others) to make independent releases, whenever they are needed.

X.Org has decided that the best tools to manage the build of this new modularized source tree are the GNU auto-tools. They have an existing large user and developer base, and thus feel easier to use by the majority of developers. Being maintained outside of the X.Org project is supposed to lower the maintenance burden on the X developers which are now free to concentrate on their code. The gnome pkg-config tool is used to keep track of version dependencies between new modules.

And how does this all affect the OpenBSD CVS repository? To coordinate the build of the myriad of packages, I've been working on a "meta" build system, using Makefile.bsd-wrapper. I've named this system "xenocara" after the fish known to clean the aquarium's windows (http://fins.actwin.com/species/index.php?t=9&i=496). I already have a fully working X11R7.1 installation on i386, amd64 and macppc machines. Other arches will follow in the next weeks, and I will also finish merge OpenBSD local changes into the new X.

(Comments are closed)


  1. By Venture37 (217.22.94.66) venture37 (AT) hotmail DOT com on www.geeklan.co.uk

    hmm, a new fish on the scene huh, time for a fight I think!!!
    http://tinyurl.com/zjvot

    :)

  2. By kalevala (84.3.136.59) on

    I'd like to perceive. The OpenBSD X11 maintaner will use the xenocara instead of GNU autotools, or they will live together?
    With other words, X11 maintaner must use xenocara and GNU autotools also - or the OpenBSD eject the GNU autotools?
    Thank you for your answer.

    1. By Matthieu Herrb (213.41.176.184) on

      > I'd like to perceive. The OpenBSD X11 maintaner will use the xenocara instead of GNU autotools, or they will live together?
      > With other words, X11 maintaner must use xenocara and GNU autotools also - or the OpenBSD eject the GNU autotools?

      Xenocara is a set of Makefile.bsd-wrapper style makefiles to drive autotools.
      We have a MIT-licensed replacement for pkgconfig to use there.


      1. By Anonymous Coward (156.34.222.176) on

        > > I'd like to perceive. The OpenBSD X11 maintaner will use the xenocara instead of GNU autotools, or they will live together?
        > > With other words, X11 maintaner must use xenocara and GNU autotools also - or the OpenBSD eject the GNU autotools?
        >
        > Xenocara is a set of Makefile.bsd-wrapper style makefiles to drive autotools.
        > We have a MIT-licensed replacement for pkgconfig to use there.
        >
        >
        >

        I'm thinking/wondering two things:

        First this is a great opportunity to weed out accumulated fluff and cruft from X -- perhaps moving some of it to ports (or nowhere at all; Does anyone really need or want xeyes?)

        I'm assuming there are still some other GNU autotools dependencies? I'm wondering will the necessary tools require installation autotools installation from ports, or will the necessary autotools be imported into the GNU portion of the source tree? It is nice to keep the GNU stuff to a minimum, but I guess 'ya need what ya need'. Not a big deal either way, I'm just curious.

        1. By Anonymous Coward (66.225.162.55) on

          >
          > First this is a great opportunity to weed out accumulated fluff and cruft from X -- perhaps moving some of it to ports (or nowhere at all; Does anyone really need or want xeyes?)

          Yes, it plays a critical role is guarding my server room.

        2. By Igor Sobrado (156.35.26.1) on

          > First this is a great opportunity to weed out accumulated fluff and cruft from X -- perhaps moving some of it to ports (or nowhere at all; Does anyone really need or want xeyes?)

          Yes, period. We need all these tools. We *need* xclock, xclipboard, xmh, xterm and so on. These are very useful tools when running simple window managers as FVWM or mwm. xeyes and xlogo are a component of X11 too.

          xclock, xterm and so on are *required* for people not running Gnome or KDE on their machines. xclipboard is a very useful clipboard able to store hundreds of pasted (and editable!) texts concurrently. xmh is an excellent front-end to nmh. xeyes and xlogo are part of X11 too.

          I will ask not only to provide these useful components of X11 but also to fix their current bugs. xclipboard and xmh broke when XFree86 4 was released (xclipboard does not show the sliding bars on large texts or the black rectangle on lines longer than the xwindow width, xmh has issues incorporating new mail that require "resizing" the windows to refresh and update them to make it readable). All these features worked nicely on XFree86 3.x. I submitted a PR on these matters some years ago but no one cared about it.

          Oh yes, of course... we can convert X.Org on a platform to support new graphic hardware for KDE/Gnome only but, in this case, I will certainly switch to another platform that supports true X11 again! Gnome and KDE are not the way for some people here.

          1. By Anonymous Coward (72.66.71.216) on

            I understand your defense of xterm etc. (xterm is probably the most-used program for me), but why xlogo and xeyes?

            Well. I have to admit that I sometimes use xlogo to display a color. For example, "xlogo -fg \#c8c8c8" to see if that's the right shade of gray I want.

            1. By Igor Sobrado (156.35.26.1) on

              > I understand your defense of xterm etc. (xterm is probably the most-used program for me), but why xlogo and xeyes?
              >
              > Well. I have to admit that I sometimes use xlogo to display a color. For example, "xlogo -fg \#c8c8c8" to see if that's the right shade of gray I want.

              Because xlogo and xeyes are a component of X11 since 1986-87 (don't remember the date these clients were released). These small clients are not really complex ones and do not require a lot of HDD space. On OpenBSD 3.7 (sorry, X11 is not running at my home system, it is a net4801; there is no way to check sizes with release 3.9... and I have the three CDs set at home, cannot look at the OS media right now) xeyes and xlogo are 14 KB and 38 KB respectively, not too large. Source code required for xeyes is 46 KB and source code for xlogo is 66 KB long. From the CVS repository identifiers I see that these programs were last updated in april 1994 and february 2001 respectively. Changes in xlogo are probably related with supporting the render extension to X11 ("xlogo -render").

              In fact, xlogo is useful to check that the render extension is enabled too!

              IMHO, all these small clients are a part of X11 and should remain in the X11 distributions (XFree86, Xsun, Xsgi, X.Org...). If we choose removing them, why not removing xmh too? or removing xclipboard? Some people could think that ed(1) is useless too!

              I certainly do not want these clients to be removed from the X11 distributions.

              Cheers,
              Igor.

              1. By Anonymous Coward (72.66.71.216) on

                > Because xlogo and xeyes are a component of X11 since 1986-87

                I don't see why that means we should keep them. Tradition for tradition's sake?

                > These small clients are not really complex ones and do not require a lot of HDD space.

                This is a good point. In fact:

                -rwxr-xr-x 1 root wheel 11.0K Mar 10 13:36 /usr/X11R6/bin/xeyes
                -rwxr-xr-x 1 root wheel 34.8K Mar 10 13:36 /usr/X11R6/bin/xlogo

                I guess there's no real benefit to removing 45.8K for the sake of saving 45.8K. The trade-off: we use an extra 46K of disk space, and, if someone down the road misses these programs they don't have to do a pkg_add.

                > In fact, xlogo is useful to check that the render extension is enabled too!

                That's kind of silly, when there's:

                $ xdpyinfo | grep RENDER

                1. By Igor Sobrado (81.35.156.200) on

                  > > Because xlogo and xeyes are a component of X11 since 1986-87
                  >
                  > I don't see why that means we should keep them. Tradition for tradition's sake?

                  We should not remove an OS component without a good reason to do it. Replacing RCS and CVS with OpenCVS makes sense to me, as we will have a clean, audited and maintained revision control system (and it is even more important for CVS, as it allows remote repositories reachable from untrusted hosts). Same about replacing GNU's gzip with a front-end to the zlib library. But removing a small and stable client that most Unix users will expect in the X11 distribution only because it is not widely used does not seem right to me.

                  > > In fact, xlogo is useful to check that the render extension is enabled too!
                  >
                  > That's kind of silly, when there's:
                  >
                  > $ xdpyinfo | grep RENDER

                  Well, we know if the render extension is enabled looking at the output of xdpyinfo, but xlogo shows how an application will look when using this extension too. It shows how a render-enabled client must look and if this extension is working as we expect in our current hardware. (e.g., will the render extension work on an old X/Terminal connected to an X server using XDMCP?)

        3. By Anonymous Coward (199.18.139.160) on

          >Does anyone really need or want xeyes?)

          Go ahead and send the diff. Of course it will have to be maintained as a separate package, ugh. Sounds like more work than to just leave it in.

        4. By Anonymous Coward (87.186.102.213) on

          > Does anyone really need or want xeyes?)

          Yes. I use them on all my desktop machines.

  3. By Anonymous Coward (81.57.42.108) on

    Does this means that OpenBSD cvs will import gnome's pkg-config ?

    GNU autohell seems less likely of course ... so what will be the alternative ? will the OpenBSD's cvs import pre-configured (in the autoconf sense) sources ?

    How will you avoid the heavy burden to merge a different build system, at every resync beetween OpenBSD's cvs and x.org's one ?

    Does the new x.org version brings good things (beside drivers) for OpenBSD ? specifically: will it provide a better support for old/minority architectures (could it obsolete xfree3) ?

    Also: will we have yet an other - the third, beside X11 (XFree3) and XF4 (XFree4) - X11 sources cvs module in the OpenBSD cvs, or will the others be removed ?

    1. By Anonymous Coward (74.71.191.127) on

      > Also: will we have yet an other - the third, beside X11 (XFree3) and XF4 (XFree4) - X11 sources cvs module in the OpenBSD cvs, or will the others be removed ?
      >

      Oh please NO (do not remove XFree3) - it gets slower and buggier by the release, and if you've ever compared XFree3 vs. others on "lowend" hardware you'll know exactly what I speak of.

  4. By Anonymous Coward (216.220.225.229) on

    I think the subject says it all.

    1. By Justin (216.17.68.210) on

      > I think the subject says it all.

      <hopeless hope>
      Or less likely it will get moved to the attic for a replacement of Xorg called OpenX or maybe they'd rename it to OpenWindows. Redmond might not like that though.
      </hopeless hope>

      1. By Anonymous Coward (86.194.71.163) on

        > <hopeless hope>
        > Or less likely it will get moved to the attic for a replacement of Xorg called OpenX or maybe they'd rename it to OpenWindows. Redmond might not like that though.
        > </hopeless hope>

        That's just stupid. What the hell is wrong with Xorg? So they decided to switch from imake to GNU autotools, big fucking deal. What a stupid reason to call for the creation of another implementation of X Windows. Shouldn't you be calling for the creation of some sort of BSD-licensed autoconf/automake/pkgconfig replacement if you really are that irrationally opposed to the idea of a piece of the base system requiring GPL'd software to build?
        In fact, just because modular Xorg requires GNU autotools to compile doesn't mean GNU autotools needs to become part of the base system. Being only required for _building_, they can remain in the ports tree.

        1. By Anonymous Coward (70.27.15.123) on

          > > <hopeless hope>
          > > Or less likely it will get moved to the attic for a replacement of Xorg called OpenX or maybe they'd rename it to OpenWindows. Redmond might not like that though.
          > > </hopeless hope>
          >
          > That's just stupid. What the hell is wrong with Xorg?

          Its a loonix-centric, poorly designed security hole? Its stupid desire to have direct access to my hardware, and thus the ability to totally lock up my machine?

          1. By Anonymous Coward (71.96.189.16) on

            > Its a loonix-centric, poorly designed security hole? Its stupid desire to have direct access to my hardware, and thus the ability to totally lock up my machine?

            So... don't use it? *gasp*

            1. By Anonymous Coward (70.27.15.123) on

              > > Its a loonix-centric, poorly designed security hole? Its stupid desire to have direct access to my hardware, and thus the ability to totally lock up my machine?
              >
              > So... don't use it? *gasp*

              I have no choice. Are you really this stupid? He asked what's wrong with Xorg. I told him. Why are you posting complete bullshit like this?

              1. By Anonymous Coward (128.171.90.200) on

                > > So... don't use it? *gasp*
                >
                > I have no choice.

                sure you do, just don't install it

                1. By Anonymous Coward (84.217.45.124) on

                  > > I have no choice.
                  >
                  > sure you do, just don't install it

                  Yes, good suggestion there Timmy. pkg_delete the bastard or skip it during a reinstall and then tell your boss why you couldn't finish the work you've been assigned because someone on the Internet told you, you have a choice. Have you ever thought about a career as a politician? You'd make a great one.

                  -"Hi there! I have no idea who you are or what you do and frankly I don't give a damn, but you have a choice."
                  "Do I?"
                  -"Yes, but either way, you're fucked."

        2. By Anonymous Coward (71.126.111.37) on

          The problem isn't that autoconf isn't that it's GPL; it's that it sucks. I can't imagine what sort of perverse mind would start out with the idea of building a cross-platform, multi-architecture way to build software, and manage to make something that is as hostile to popular software and hardware combinations, as well as being as generally unportable, as GNU autoconf is (if you've ever tried to compile most sourceforge projects directly from a source tarball while not on a Linux/x86 system, you know what I mean).

          Most software, if written properly, shouldn't require more than a Makefile. If that is not enough, chances are the software is written in a completely unportable manner anyway

          1. By SH (82.182.103.172) on

            > The problem isn't that autoconf isn't that it's GPL; it's that it sucks.

            The release manager of Subversion made that pretty clear in the link for a release candidate after a newer autoconf messed things up ;-)

            http://lolut.utbm.info/subversion/1.4.0/rc3/i_hate_autoconf/

            1. By Anonymous Coward (24.119.18.143) on

              > > The problem isn't that autoconf isn't that it's GPL; it's that it sucks.
              >
              > The release manager of Subversion made that pretty clear in the link for a release candidate after a newer autoconf messed things up ;-)
              >
              > http://lolut.utbm.info/subversion/1.4.0/rc3/i_hate_autoconf/
              >

              link bad - is there an alternative?

      2. By Anonymous Coward (72.66.71.216) on

        Uhh, the name OpenWindows has been around for awhile... wikipedia entry

  5. By Noryungi (83.202.34.116) n o r y u n g i @ y a h o o . c o m on

    Since the Xenocara is such an ugly fish... Is that a little jab intended for the X.org programmers? :-)

    1. By Anonymous Coward (63.237.125.164) on

      Beauty is in the eye of the beholder.

      1. By Anonymous Coward (64.231.139.29) on

        > Beauty is in the eye of the beholder.
        >

        Beauty is defined by elitest and patriarchal propaganda.

        1. By Anonymous Coward (70.169.167.212) on

          > > Beauty is in the eye of the beholder.
          > >
          >
          > Beauty is defined by elitest and patriarchal propaganda.
          >

          And the Gloria Steinem minions raise their ugly heads again! The place for that is the Nat'l Org. for Women forum, not Undeadly.org. Let's keep it technical here, shall we?

  6. By Anonymous Coward (203.58.120.11) on

    Are there any plans to implement DRM/DRI? A good, minimal kernel-side video driver could avoid most of the problems that loic spoke of....

    1. By Anonymous Coward (72.66.71.216) on

      Speaking of personal wishlists, I'd like to know when Xorg will support s-video output on radeons... I guess that's something to bitch the Xorg people about, not OpenBSD. But, I've been waiting for that feature for years, and yet nobody really cares since ATI's crummy blob drivers support it on Linux.

      1. By Anonymous Coward (69.246.68.23) on

        > But, I've been waiting for that feature for years, and yet nobody really cares since ATI's crummy blob drivers support it on Linux.

        This sounds exactly like how maintance of wifi drivers in linux have lagged because of the windows driver wrappers.

        Isn't there a less-functional open source ati solution? ati-gatos ? I am not sure, I just installed it for somebody on linux some 5 years ago. I think it supported alot the silly stupid features of an ati all-in-wonder. Maybe look into that. And this was before X.org.

        1. By Anonymous Coward (72.66.71.216) on

          > Isn't there a less-functional open source ati solution? ati-gatos?

          Yeah, but last I checked it was a pain to build on OpenBSD. There is also a patch against Xorg's driver, but it is GPL.

          Still, a GPL'd driver is better than none, so one day when I have lots of "recompile X with patches written by linux folk which may or may not work" time, I may try to get it working.

          Don't get me wrong, the ati driver in tree right now works very very well for me, I am pleased with it. I just want s-video output, which is not presently supported.

          Last I heard somebody was tryng to get the guy that wrote the GPL patch to agree to an X licence. That was a year ago.

  7. By Simon 'simmel' Lundström (213.112.203.160) on

    Just for the record, their site is at http://xenocara.org/

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]