Yeah, you're right on the money about the architecture, except that we also 
have a hardware specific userspace driver that the windowing system uses to 
either take care of video operations with MMIO or by sending the command to the 
kernel driver.  My plan is to replace the kernel drivers with drm drivers.  
After that, I'll remove the windowing system's dependence on the video driver & 
instead link it to libGL.  At that point, I would have already gotten DRI to 
build successfully.  The one thing that really stumps me is providing DRM 
capabilities fully as they are in Linux, considering that a lot of our hardware 
abstractions are completely different.  Also, is there any DRM state info 
that's stored and active in drm.ko?  I've also tried to do this without 
touching the stuff in shared-core, but there are some things in there that 
doesn't quite fit with Syllable, but are needed for DRM.  I may have to add 
some '#ifdef's' to a few of the headers.  There are some things that pretty 
much expect to be compiled in an XWindow's environment.  Also, we support 
shared object loading, however we can't reference functions from one driver to 
the next.

Dee Sharpe


 


 

-----Original Message-----
From: Nicolai Hähnle <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; dri-devel@lists.sourceforge.net
Sent: Wed, 6 Aug 2008 2:43 am
Subject: Re: [Mesa3d-dev] DRM question










Am Mittwoch 06 August 2008 02:53:23 schrieb [EMAIL PROTECTED]
cape.net:
> I've been working on a port of DRM for Syllable.? Syllable doesn't support
> drivers (or kernel modules) that are on the same level of abstraction &
> communicate with each other.? For example our sound card drivers can't
> communicate with any other driver normal driver, they can only communicate
> with busmanagers (PCI, ISA, etc.).? With this in mind, I've been wondering
> what the signifigance of having a drm kernel object that's seperate from
> the video driver, but the video driver is dynamicly linked to it.? If I
> have gotten something wrong, please let me know.? Also, is it a big deal to
> just compile all of the drm driver code into the video drivers?? I ask
> this, not because I'm trying to change the way you all do things, but only
> because I'm trying to find a suitable solution for Syllable.

It's been a very long time since I last looked into Syllable, but if I 
remember things correctly, the setup was something like:

1. Hardware-specific video driver in the kernel
2. Hardware agnostic server in userspace that manages the desktop

The Linux setup is like this:

1. Hardware-independent kernel module "drm"
2. Hardware-specific kernel module, e.g. "radeon"
3. Hardware-specific module in the Xserver

Since you already have a hardware-specific module in the kernel, I think it's 
reasonable to merge the hardware-specific parts of the drm into that existing 
module.

After all, when you have two hardware-specific modules in the kernel you only 
end up having to worry
 about interface compatibility issues when people run 
versions of the modules that don't match (alternatively you could force the 
module versions to be the same, but then why separate things into two 
different modules in the first place).

As for the hardware-independent kernel bits (the "drm" module), perhaps you 
should think of them not as a driver but as a kind of shared library that 
contains utility functions for writing a driver?

Once you're in that mindset of the "drm" bits being a library, and if the 
Syllable kernel really doesn't support shared library loading (that's a very 
odd design decision), you could always build them as a static library that is 
linked into each of the hardware-specific drivers. So if that was your 
original question, no, I don't think it's a big deal if that's the way 
Syllable works.

The important thing is that it should be possible to do all this without 
touching the shared-core directory by putting the Syllable-specific things in 
their own directory (as is the case for Linux and BSD today).

cu,
Nicolai



 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to