OpenBSD Journal

Matthieu Herrb gets seat in BoD of X.org

Contributed by jj on from the we-demand-X12-by-now dept.

The X.Org Foundation Board Election is complete, and Matthieu Herrb was amongst those who got the top votes, earning him a place in the Board of Directors for the next two years.
The complete announcement is available here.

As the X.org site notes, "The X.Org Foundation, L.L.C. has only personal membership, therefore the Board Members don't represent their employers or affiliations.", it is not a seat for OpenBSD but for him personally, but we can rest assured he will do his best to keep X.org free from weird licenses and generally continue to do a good job at helping X11 forward.

Also worth noting is that for those who want to help X.org by joining up as a member, the membership is free of charge. Visit members.x.org to join.

(Comments are closed)


Comments
  1. By Anonymous Coward (81.83.46.237) on

    This is really great news, congratulations Matthieu! So he can make sure x.org stays for Unix and not becomes Linux only software.

    Comments
    1. By David Chisnall (82.7.199.50) on

      > This is really great news, congratulations Matthieu! So he can make sure x.org stays for Unix and not becomes Linux only software.

      Eric Anhold, DRI maintainer for FreeBSD was also elected. Looks like the BSDs are pretty well represented by this new board.

      Slightly off-topic: There was apparently a presentation about DRI on OpenBSD at OpenCON. Does anyone know if / when / where the slides are going to be published?

      Comments
      1. By oga (155.198.68.50) on

        > > This is really great news, congratulations Matthieu! So he can make sure x.org stays for Unix and not becomes Linux only software.
        >
        > Eric Anhold, DRI maintainer for FreeBSD was also elected. Looks like the BSDs are pretty well represented by this new board.
        >
        > Slightly off-topic: There was apparently a presentation about DRI on OpenBSD at OpenCON. Does anyone know if / when / where the slides are going to be published?


        Sorry, I'd forgotten about that.

        I'll try and get them up soon.

  2. By Andrés Delfino (201.212.132.25) adelfino@gmail.com on

    Congratulations, Matthieu!

  3. By saad (88.167.166.155) on

    Congratulations Matthieu!!!!

  4. By Anonymous Coward (24.37.242.64) on

    Congratulations Matthieu!!!

  5. By Brynet (Brynet) on

    That's pretty cool... good luck Matthieu.

    Does anyone else notice an "Xorg" membership requires "way" too much personal information?

    It must be a joke... in this day and age, people like their anonymity..

    Comments
    1. By Anonymous Coward (81.83.46.237) on

      > It must be a joke... in this day and age, people like their anonymity..

      If you read what "mebership" means, I personally don't think they ask too much: http://www.x.org/wiki/Membership

  6. By Anonymous Coward (69.70.68.38) on

    I think it's great that he's a BSD guy to do this, but what's the overall purpose/advantage of such a postition?

    Comments
    1. By Anonymous Coward (213.118.238.47) on

      > I think it's great that he's a BSD guy to do this, but what's the overall purpose/advantage of such a postition?

      I just picked this up from the mailing list:
      http://marc.info/?l=openbsd-misc&m=114738577123893&w=2

      To quote an interesting part:
      "But let me be clear -- the X developers are a bunch of shameless
      vendor-loving lapdogs who sure are taking their time at solving this >
      10 year old problem! They spend way more time chasing the latest
      vendor binary loaded device driver, than they do solving this obvious
      problem. (Translation: They don't want to change how X works, because
      it would break the vendor binary drivers from ATI and NVIDIA. That is
      part of what happens when X developers get jobs at vendors)."

      So maybe having an OpenBSD minded developer in the Board of Directors for the next two years can mean a difference. (or that's what I'm hoping for)

      Comments
      1. By Anonymous Coward (83.17.211.222) on

        > > I think it's great that he's a BSD guy to do this, but what's the overall purpose/advantage of such a postition?
        >
        > I just picked this up from the mailing list:
        > http://marc.info/?l=openbsd-misc&m=114738577123893&w=2
        >
        > To quote an interesting part:
        > "But let me be clear -- the X developers are a bunch of shameless
        > vendor-loving lapdogs who sure are taking their time at solving this >
        > 10 year old problem! They spend way more time chasing the latest
        > vendor binary loaded device driver, than they do solving this obvious
        > problem. (Translation: They don't want to change how X works, because
        > it would break the vendor binary drivers from ATI and NVIDIA. That is
        > part of what happens when X developers get jobs at vendors)."
        >
        > So maybe having an OpenBSD minded developer in the Board of Directors for the next two years can mean a difference. (or that's what I'm hoping for)

        That quote is about security bug (design error) and of course it's X
        fault. In part that's true, but could anyone tell me why OpenBSD
        didn't design sane kernel-level video drivers? Linux has framebuffer
        interface and X can use it. What interfaces did OpenBSD design to
        solve that problem?

        Comments
        1. By Andrés Delfino (200.80.164.3) adelfino@gmail.com on

          Does video belong to the kernel at all?

          Comments
          1. By Anonymous Coward (83.17.211.222) on

            > Does video belong to the kernel at all?

            According to Theo -- yes, quoting:
            http://marc.info/?l=openbsd-misc&m=114738577123893&w=2

            "How does this get solved?

            If the X server did not require direct hardware access these problem
            would go away immediately.

            This requires that a proper abstraction be designed, so that a kernel
            device driver did the nasty register bits, and then communicated via a
            sanitized channel to the X server. This is the obvious seperation model
            that all other Unix things use. Unix processes use read() and write()
            to modify files. You don't see them talking directly to SATA chipsets
            do you?

            If they show up and provide a simple specification for such an
            abstration layer between a "kernel video driver" and a "X video
            driver", and helped us a little bit with the registers, the problem
            would go away almost immediately. That requires them to do some
            clever design, but it is clear they know more about past, current, and
            future video chipsets. They know the hardware, and we do not. They
            can solve this for all X-running operating systems today, or they can
            cop out and not solve it ever."

            The problem is question who should do the design.
            Theo in his usual tone says that's Xorg problem.
            Xorg designed things differently, but maybe they
            too have the point?

            According to http://lxr.linux.no/linux/Documentation/fb/vesafb.txt
            Linux's VESA framebuffer driver uses BIOS to set videomode:

            # This means we decide at boot time whenever we want to run in text or
            # graphics mode. Switching mode later on (in protected mode) is
            # impossible; BIOS calls work in real mode only. VESA BIOS Extensions
            # Version 2.0 are required, because we need a linear frame buffer.

            I _guess_ Xorg uses VM86 extensions and that's impossible/not wanted
            in the kernel.

            Whatever details are (I'm no expert here) simply blaming others doesn't
            move us forward.

            Comments
            1. By Anonymous Coward (204.80.187.9) on

              > > Does video belong to the kernel at all?
              >
              > Whatever details are (I'm no expert here) simply blaming others doesn't
              > move us forward.

              You're right. We need you to help us figure this out and move things forward. Please help. Nobody else knows what's going on!

              Comments
              1. By Anonymous Coward (83.17.211.222) on

                > > > Does video belong to the kernel at all?
                > >
                > > Whatever details are (I'm no expert here) simply blaming others doesn't
                > > move us forward.
                >
                > You're right. We need you to help us figure this out and move things forward. Please help. Nobody else knows what's going on!

                Nice one. :)

                For those interested in facts, see: http://lwn.net/Articles/218380/

                "Looking further ahead, the X developers would like to move video card mode setting into the kernel. There are a lot of reasons for doing this, starting with simple robustness. It would also enable better suspend and resume support, and better handling of panics: if the system goes into an oops, an in-kernel mode-setting routine can switch back to a text mode, allowing the oops text to actually be read."

            2. By Tobias Weingartner (68.151.168.15) weingart@tepid.org on http://www.tepid.org/~weingart/


              The one thing I've always wondered, why are the X people not pushing
              the vendors (of which there are really only two left) for a simple X
              like pipeline with an open specification. A way to set video modes,
              query the monitor info, etc?

              It may not be the fastest, and that would be why you'd run binary
              crap, but it would be more than fast enough to do X stable...

              -T.

              Comments
              1. By Anonymous Coward (24.37.242.64) on

                >
                > The one thing I've always wondered, why are the X people not pushing
                > the vendors (of which there are really only two left) for a simple X
                > like pipeline with an open specification. A way to set video modes,
                > query the monitor info, etc?
                >
                > It may not be the fastest, and that would be why you'd run binary
                > crap, but it would be more than fast enough to do X stable...
                >
                > -T.

                Maybe they're wuss's like the Linux developers or other developers who don't have the balls to stand up like Theo and others do? Just a guess.

                Some would rather just take it, than stand up and fight for what they believe in.

                - If you don't fight for what you believe in, then why believe in it?



        2. By sthen (85.158.45.32) on

          > What interfaces did OpenBSD design to solve that problem?

          OpenBSD has wsfb(4) on some arch (iirc, sparc/sparc64/macppc/zaurus) which doesn't require the aperture driver.

          Comments
          1. By Brad (216.138.195.228) brad at comstyle dot com on

            > > What interfaces did OpenBSD design to solve that problem?
            >
            > OpenBSD has wsfb(4) on some arch (iirc, sparc/sparc64/macppc/zaurus) which doesn't require the aperture driver.

            This is not an adequate solution to the problem.

  7. By Anonymous Coward (81.56.217.26) on

    Thank you Keith,
    for making a pre-alpha software a standard bottleneck (namely xft/fontconfig),
    for making unusable the only screen readable fonts (namely bdf/pcf),
    for making patented algorithms a necessity (namely ttf bytecode interpreter),
    for making a configuration file that will be overwritten on every update (namely /etc/fonts/fonts.conf).

    Thank you Keith PACKARD for making fontconfig (sic), and creating/directing X.org to make sure it will be on every *NIX.

  8. By Bayu Krisnawan (222.124.156.122) krisna@versalite.com on http://www.infobsd.org

    Congratulations Matthieu,
    With the OpenBSD Spirit will be survive!.

    Let's rockz X.org with freedom like the air.

  9. By Anonymous Coward (85.178.104.253) on

    Well what can he do about a brocken design?

    Except of a "fully working X Server for everybody" Xorg may should focus on OS indipendent drivers and specify just an API wich has to get implemented by each OS itself.
    That may would help to reduce some headaches we face with the "Xorg Server" we're all using right now.

    This also would mean that the API would need to get into the Kernel but even Theo said that MS did a good job by combining the graphic "Server" into the Kernel.

Latest Articles

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.]