Menu
▾
▴
linux-fbdev-devel
|
From: Jon S. <jon...@ya...> - 2003-01-14 02:02:11
|
Does it make sense to try merging the DRM drivers into the video directory? Maybe something like this: video -- empty except for Kconfig file video/console -- generic fbconsole code video/DRM -- generic DRM code video/ati -- ati drivers (drm & fb) video/i810 -- i810 drivers (drm & fb) etc..... This would allow the merging of the DRM and FB hardware device drivers over time. Switching VTs should be coordinated with saving 3D state. Even with out merging DRM should the console driver be split out from the hardware drivers? ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Sven L. <lu...@dp...> - 2003-01-14 09:13:21
|
On Mon, Jan 13, 2003 at 06:02:07PM -0800, Jon Smirl wrote: > Does it make sense to try merging the DRM drivers into > the video directory? Maybe something like this: > > video -- empty except for Kconfig file > video/console -- generic fbconsole code > video/DRM -- generic DRM code > video/ati -- ati drivers (drm & fb) > video/i810 -- i810 drivers (drm & fb) > etc..... > > This would allow the merging of the DRM and FB > hardware device drivers over time. Switching VTs > should be coordinated with saving 3D state. > > Even with out merging DRM should the console driver be > split out from the hardware drivers? I think Linus rejected this last time James submitted it. That said, there is a trend with the DRI people that now want to use the drm modules to do memory allocation or something such, which was, i think, previously done in the X server. Maybe this would be of interrest to a fbdev<->drm merging James did speak about some time ago. Friendly, Sven Luther |
|
From: Jon S. <jon...@ya...> - 2003-01-14 17:22:36
|
--- Sven Luther <lu...@dp...> wrote: > I think Linus rejected this last time James > submitted it. Didn't the last patch just move the DRM directory from driver/char into the video directory.? This could be done in two steps. First split out the fb console driver files into their own directory and then sort out the hardware drivers more. Then if the DRM merge gets ok'd everything will be ready. In the config system I don't like how you have to enable driver support for the same piece of hardware in two different places. I also don't like looking in two different places for the source to drivers for the same hardware. What is Linus' take on merging a card's fb and drm drivers into a single module in the long run? ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Sven L. <lu...@dp...> - 2003-01-14 21:26:57
|
On Tue, Jan 14, 2003 at 09:22:36AM -0800, Jon Smirl wrote: > --- Sven Luther <lu...@dp...> wrote: > > I think Linus rejected this last time James > > submitted it. > > Didn't the last patch just move the DRM directory from > driver/char into the video directory.? There is a response of linus in the mailing list archive about this, i don't remember nor checked if it was only the first time, or not. I think the objection was about complicate to supervise diffs. > This could be done in two steps. First split out the > fb console driver files into their own directory and > then sort out the hardware drivers more. Then if the > DRM merge gets ok'd everything will be ready. > > In the config system I don't like how you have to > enable driver support for the same piece of hardware > in two different places. I also don't like looking in > two different places for the source to drivers for the > same hardware. > > What is Linus' take on merging a card's fb and drm > drivers into a single module in the long run? Well, the problem is that the fb drivers are maintained by us, and the drm drivers are maintained by the DRI. Also, i think the drm drivers should compile not only on linux, but on other oses too (BSDs at least). Also, i believe some of the XFree86 guys don't like fbdevs. Friendly, Sven Luther |
|
From: James S. <jsi...@in...> - 2003-01-15 00:39:04
|
> There is a response of linus in the mailing list archive about this, i > don't remember nor checked if it was only the first time, or not. I > think the objection was about complicate to supervise diffs. Yes. The DRI people want to keep there work seperate from us. > Also, i think the drm drivers should compile not only on linux, but on > other oses too (BSDs at least). That will be difficult. The VM layer to BSD is very very different from linux. There is no way they coudl use the same code set for both without making a mess. > Also, i believe some of the XFree86 guys don't like fbdevs. :-( |
|
From: Geert U. <ge...@li...> - 2003-01-15 09:41:36
|
On Wed, 15 Jan 2003, James Simmons wrote:
> > Also, i think the drm drivers should compile not only on linux, but on
> > other oses too (BSDs at least).
>
> That will be difficult. The VM layer to BSD is very very different from
> linux. There is no way they coudl use the same code set for both without
> making a mess.
I think Sven meant the userspace part of DRM. Of course the actual kernelspace
implementation differs.
> > Also, i believe some of the XFree86 guys don't like fbdevs.
>
> :-(
Yes indeed :-(
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Michel <mi...@da...> - 2003-01-15 21:38:37
|
On Mit, 2003-01-15 at 01:37, James Simmons wrote: > > There is a response of linus in the mailing list archive about this, i > > don't remember nor checked if it was only the first time, or not. I > > think the objection was about complicate to supervise diffs. > > Yes. The DRI people want to keep there work seperate from us. While I hope there will be some form of cooperation between framebuffer devices and the DRM in the future, I do think they basically serve very different purposes so I don't think merging them makes sense. > > Also, i think the drm drivers should compile not only on linux, but on > > other oses too (BSDs at least). > > That will be difficult. The VM layer to BSD is very very different from > linux. There is no way they coudl use the same code set for both without > making a mess. Probably, but keeping all code separate for all supported OSs would be at least as big a mess, so we share as much code as possible via a template mechanism. The BSD specific parts aren't in the Linux kernel of course. > > Also, i believe some of the XFree86 guys don't like fbdevs. > > :-( Luckily, those aren't part of the DRI project AFAICT. On the contrary, several DRI developers have declared interest in supporting framebuffer devices, and at least one of them is working on 'an embedded radeon 3d driver that lives on top of fbdev' in Mesa CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Jon S. <jon...@ya...> - 2003-01-16 03:52:31
|
--- Michel Dänzer <mi...@da...> wrote: > While I hope there will be some form of cooperation > between framebuffer > devices and the DRM in the future, I do think they > basically serve very > different purposes so I don't think merging them > makes sense. Some areas of cooperation..... 1) We have two drivers for the same hardware. They should be sharing the same include files describing the hardware. 2) Bug fixing, in some cases the same hardware bug would need to be fixed in two places. 3) State saving. When the virtual terminal is changed is the complete state of the DRM driver saved? What if one of the other virtual terminals plays with 3D mode? 4) DDC and secondary reset support. I was looking at adding this to some of the framebuffer drivers. The X driver can't share this code. 5) General kernel config. The same peice of hardware appears in two different places. There is no immediate reason for merging. I am just thinking about where this will be in three to five years. A more general question, what should be the capabilities of an in kernel video driver? Required: 1) Complete state save on VT switch 2) Security and control of DMA hardware Maybe required: 1) Reset and initialize hardware 2) Video mode change 3) Power saving Not clear if better in user or kernel space: 1) copy, fill, blit, etc in current fb interface Where is the right place to draw the link between kernel and user space for video drivers? ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Sven L. <lu...@dp...> - 2003-01-16 10:39:00
|
On Wed, Jan 15, 2003 at 07:52:31PM -0800, Jon Smirl wrote: > --- Michel D?nzer <mi...@da...> wrote: > > While I hope there will be some form of cooperation > > between framebuffer > > devices and the DRM in the future, I do think they > > basically serve very > > different purposes so I don't think merging them > > makes sense. > > Some areas of cooperation..... > > 1) We have two drivers for the same hardware. They > should be sharing the same include files describing > the hardware. > 2) Bug fixing, in some cases the same hardware bug > would need to be fixed in two places. > 3) State saving. When the virtual terminal is changed > is the complete state of the DRM driver saved? What if > one of the other virtual terminals plays with 3D mode? Currently, mostly the state saving code is in the X server anyway, so it would not help here. > 4) DDC and secondary reset support. I was looking at > adding this to some of the framebuffer drivers. The X > driver can't share this code. > 5) General kernel config. The same peice of hardware > appears in two different places. Also, i believe that some discution about the sharing of fb memory and other such may be in common. Also, there could be the possibility (remote possiblity though) that the fbdev driver author and the DRI author is the same person. > There is no immediate reason for merging. I am just > thinking about where this will be in three to five > years. > > A more general question, what should be the > capabilities of an in kernel video driver? > > Required: > 1) Complete state save on VT switch This is done in the X server right now, altough i believe the fbdev also does save its state on VT exit. > 2) Security and control of DMA hardware done in the drm module. > Maybe required: > 1) Reset and initialize hardware > 2) Video mode change > 3) Power saving Currently duplicated in the X server and the fbdev driver. Mmm, maybe X does not know about power saving, since i think the dri/ati people leave the X VT for fbdev before going in power saving mode. > Not clear if better in user or kernel space: > 1) copy, fill, blit, etc in current fb interface This is common between X and fbdev. The architecture and the needs are different, though, so i don't believe there will be anything shareable here. Also i thought Linus would not accept anything beyond console acceleration stuff in the kernel anyway. > Where is the right place to draw the link between > kernel and user space for video drivers? All accel except basic console driving code we have right now go to userspace. DMA, security control and irq handling need to be in the kernel though. Friendly, Sven Luther > > > > > > ===== > Jon Smirl > jon...@ya... > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > ------------------------------------------------------- > This SF.NET email is sponsored by: A Thawte Code Signing Certificate > is essential in establishing user confidence by providing assurance of > authenticity and code integrity. Download our Free Code Signing guide: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: Michel <mi...@da...> - 2003-01-16 20:14:19
|
On Don, 2003-01-16 at 04:52, Jon Smirl wrote: > > 1) We have two drivers for the same hardware. They > should be sharing the same include files describing > the hardware. Might be a good idea. > 2) Bug fixing, in some cases the same hardware bug > would need to be fixed in two places. Not sure about this, as I don't see much overlap, but it's plausible I guess. > 3) State saving. When the virtual terminal is changed > is the complete state of the DRM driver saved? What if > one of the other virtual terminals plays with 3D mode? A 3D driver (at least an OpenGL driver) needs to always keep track of hardware state anyway, so after a VT switch it can just upload everything it needs again. > 4) DDC and secondary reset support. I was looking at > adding this to some of the framebuffer drivers. The X > driver can't share this code. The framebuffer device could offer interfaces for these though? > 5) General kernel config. The same peice of hardware > appears in two different places. For very different purposes. Anyway, couldn't the config hierarchy be changed without moving code around, at least with Kconfig? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
Thanks for helping keep SourceForge clean.
X