Contributed by jj on from the we-demand-X12-by-now dept.
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)
By Anonymous Coward (81.83.46.237) on
Comments
By David Chisnall (82.7.199.50) on
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
By oga (155.198.68.50) on
>
> 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.
By Andrés Delfino (201.212.132.25) adelfino@gmail.com on
By saad (88.167.166.155) on
By Anonymous Coward (24.37.242.64) on
By Brynet (Brynet) on
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
By Anonymous Coward (81.83.46.237) on
If you read what "mebership" means, I personally don't think they ask too much: http://www.x.org/wiki/Membership
By Anonymous Coward (69.70.68.38) on
Comments
By Anonymous Coward (213.118.238.47) on
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
By Anonymous Coward (83.17.211.222) on
>
> 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
By Andrés Delfino (200.80.164.3) adelfino@gmail.com on
Comments
By Anonymous Coward (83.17.211.222) on
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
By Anonymous Coward (204.80.187.9) on
>
> 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
By Anonymous Coward (83.17.211.222) on
> >
> > 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."
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
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?
By sthen (85.158.45.32) on
OpenBSD has wsfb(4) on some arch (iirc, sparc/sparc64/macppc/zaurus) which doesn't require the aperture driver.
Comments
By Brad (216.138.195.228) brad at comstyle dot com on
>
> 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.
By Anonymous Coward (81.56.217.26) on
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.
By Bayu Krisnawan (222.124.156.122) krisna@versalite.com on http://www.infobsd.org
With the OpenBSD Spirit will be survive!.
Let's rockz X.org with freedom like the air.
By Anonymous Coward (85.178.104.253) on
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.