What's the minimum I need to port over to have something working?
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]:
> 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=/
_______________________________________________
Mesa3d-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-------------------------------------------------------------------------
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
