Re: Article on state of graphics drivers on BSDs

[Martin <martin.kelly4000%gmail.com@localhost>]

> On Mon, Feb 11, 2013 at 6:50 AM, John Nemeth <jnemeth%victoria.tc.ca@localhost> wrote:
>     The issue is that at one time, just about all drivers for x86 were

> fully implemented in userland, so all that was needed from the kernel
> was a way for userland to directly access the hardware.  This meant
> that all X.org (or XF86) drivers would work on all systems without
> issue.

>     This is no longer true.  Modern drivers don't have direct access
> to the hardware and require quite a bit of kernel support.  There are
> two issues here.  The first is that there is quite a bit of differences
> in kernel APIs so that you can't just take the kernel part from one
> system and plunk it on another system.  The second is that the API
> expected by the userland portion of the drivers is a rapidly moving
> target.  This is probably the bigger problem.  If it wasn't for this,
> each system would only need to work on the kernel portion once;
> however, as is, the kernel portion needs to be under constant
> developement.  This now becomes an issue of interest (open source
> developers tend to work on what interests them the most) and resource
> (in particular, time) allocation.

Yeah, with that's understood, i would really like to be able to help with Graphics Card support.

Relating to the first issue you mentioned: Kernel API's
The first problem is an obvious given, that the kernel API's of each system are going to be different unless direct they are forked and have direct compatibility with each other. So any suggestion of making head-way to unify kernel api's across all systems is out of the question.
But my second suggestion i think is a little more do-able (please correct and elaborate if i am wrong). Considering that the modules (KMS & GEOS) have not yet been ported to NetBSD and it is going to take a good 12 months for one developer to port these tools and from my understanding the two tools GEOS & KMS are not being regularly changed but are rather static modules. Would it not be possible to a) create a Wrapper based in Java that basically executes these modules (i.e. the modules requirement becomes Java) or b) re-write a portion of these modules in Java so that the modules like "a" rely on Java.
My logic is that the Java platform is not restricted by OS differences, there are many games and graphical based software. Nearly every operating system can meet the java requirement, which if these modules are "encased" (for a better word) in Java then this would mean if my theory works, that the only modifying changes to these drivers would be keeping them in sync and working with the ever changing userland drivers. 

To me it would seem that an effort to make KMS & GEOS more portable will not change anything at present in the grand scheme of things for an OS that currently does not have these graphics drivers at hand, but what it does do is provide current and future OS's the ability to easily gain access to these drivers, and possibly in time replace those same drivers that are being used by FreeBSD and Linux so that at some stage all systems are on the same page for graphics support, and its no longer a split effort with which the OS that has the biggest developing power and backing is the better off for something that really should be able to be used on all OS's.