From: Jon S. <jon...@ya...> - 2004-05-05 15:17:51
|
Is there a document describing how memory management is handled for the overall AGP/VRAM space? I've found where texture memory is handled, but who is allocating space for framebuffers on multi-head cards? If we were to redo the memory management code to support mesa-solo (ie no X present) what would need to be changed? Should this code be in the driver or user space? ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: Alex D. <ag...@ya...> - 2004-05-05 15:44:49
|
--- Jon Smirl <jon...@ya...> wrote: > Is there a document describing how memory management is handled for > the overall > AGP/VRAM space? I've found where texture memory is handled, but who > is > allocating space for framebuffers on multi-head cards? Right now the framebuffer is managed in the DDX. Alan Hourihane and Ian Romanick both have done some work on new improved memory managers for X and the DRI. > > If we were to redo the memory management code to support mesa-solo > (ie no X > present) what would need to be changed? Should this code be in the > driver or > user space? That's a good question. Alex > > ===== > Jon Smirl > jon...@ya... > > __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: Jon S. <jon...@ya...> - 2004-05-05 16:38:04
|
I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. Memory management of AGP/VRAM space is identified as a problem area but nobody has proposed any solution for it. Any solution needs to take into account FB, DRM, mesa-solo and existing Xfree. There have been a few minor comments both ways for doing it in a driver and a library. --- Alex Deucher <ag...@ya...> wrote: > > --- Jon Smirl <jon...@ya...> wrote: > > Is there a document describing how memory management is handled for > > the overall > > AGP/VRAM space? I've found where texture memory is handled, but who > > is > > allocating space for framebuffers on multi-head cards? > > Right now the framebuffer is managed in the DDX. Alan Hourihane and > Ian Romanick both have done some work on new improved memory managers > for X and the DRI. > > > > > If we were to redo the memory management code to support mesa-solo > > (ie no X > > present) what would need to be changed? Should this code be in the > > driver or > > user space? > > That's a good question. > > Alex > > > > > ===== > > Jon Smirl > > jon...@ya... > > > > > > > > > > __________________________________ > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs > http://hotjobs.sweepstakes.yahoo.com/careermakeover ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: Ian R. <id...@us...> - 2004-05-05 17:06:28
|
Jon Smirl wrote: > I'm putting together a document for Kernel Summit that describes the issues > around graphics device drivers. The kernel developers are currently making first > pass comments on it. As soon as I fold their comments in I'll post it to > fb-dev, dri-dev and wherever else is appropriate for the next round of comments. > Nobody is proposing final solutions yet, I'm just trying to collect everyone's > opinion. > > Memory management of AGP/VRAM space is identified as a problem area but nobody > has proposed any solution for it. Any solution needs to take into account FB, > DRM, mesa-solo and existing Xfree. There have been a few minor comments both > ways for doing it in a driver and a library. That's not entirely true. I made a proposal last February (search the dri-devel archives for "texmem-0-0-2") that used a combination of in-kernel and user-space. Basically, the memory management mechanism is implemented in-kernel, but the policy is implemented in user-space. |
From: Jon S. <jon...@ya...> - 2004-05-05 19:03:14
|
--- Ian Romanick <id...@us...> wrote: > That's not entirely true. I made a proposal last February (search the > dri-devel archives for "texmem-0-0-2") that used a combination of > in-kernel and user-space. Basically, the memory management mechanism is > implemented in-kernel, but the policy is implemented in user-space. Here's a link to it: http://www.mail-archive.com/dri...@li.../msg09472.html Do you have any updates to it? We can put a copy up on fd.o and I'll link it into the next round of discussions. Can any of the kernel memory management code be reused instead of building our own? Obviously this is a different pool but maybe we could use existing allocators. Are there any more design documents like this floating around that should be referenced? ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: Ian R. <id...@us...> - 2004-05-06 01:32:06
|
Jon Smirl wrote: > --- Ian Romanick <id...@us...> wrote: > >>That's not entirely true. I made a proposal last February (search the >>dri-devel archives for "texmem-0-0-2") that used a combination of >>in-kernel and user-space. Basically, the memory management mechanism is >>implemented in-kernel, but the policy is implemented in user-space. > > > Here's a link to it: > http://www.mail-archive.com/dri...@li.../msg09472.html > > Do you have any updates to it? We can put a copy up on fd.o and I'll link it > into the next round of discussions. There was one posted after that. It was posted on 3-Mar-2003. For some reason, the attachment isn't on marc. http://marc.theaimsgroup.com/?l=dri-devel&m=104673516801006&w=2 Since that point the design has changed some, but the document has not. I started writing a simulation of the design using pthreads. Some actual implementation experience exposed some problems in the design. Looking that the modification times on the files, I haven't worked on any of it since 27-May-2003. I *did* start looking at it again today. :) > Can any of the kernel memory management code be reused instead of building our > own? Obviously this is a different pool but maybe we could use existing > allocators. That's a good question. I'd probably have to talk to someone that knows better what is available in the kernel. > Are there any more design documents like this floating around that should be > referenced? |
From: Vladimir D. <vo...@mi...> - 2004-05-05 19:05:08
|
On Wed, 5 May 2004, Jon Smirl wrote: > I'm putting together a document for Kernel Summit that describes the issues > around graphics device drivers. The kernel developers are currently making first > pass comments on it. As soon as I fold their comments in I'll post it to > fb-dev, dri-dev and wherever else is appropriate for the next round of comments. > Nobody is proposing final solutions yet, I'm just trying to collect everyone's > opinion. > > Memory management of AGP/VRAM space is identified as a problem area but nobody > has proposed any solution for it. Any solution needs to take into account FB, > DRM, mesa-solo and existing Xfree. There have been a few minor comments both > ways for doing it in a driver and a library. This affects video capture as well. It would be nice to be able to reserve chunks of video ram from kernel-space. best Vladimir Dergachev > > --- Alex Deucher <ag...@ya...> wrote: > > > > --- Jon Smirl <jon...@ya...> wrote: > > > Is there a document describing how memory management is handled for > > > the overall > > > AGP/VRAM space? I've found where texture memory is handled, but who > > > is > > > allocating space for framebuffers on multi-head cards? > > > > Right now the framebuffer is managed in the DDX. Alan Hourihane and > > Ian Romanick both have done some work on new improved memory managers > > for X and the DRI. > > > > > > > > If we were to redo the memory management code to support mesa-solo > > > (ie no X > > > present) what would need to be changed? Should this code be in the > > > driver or > > > user space? > > > > That's a good question. > > > > Alex > > > > > > > > ===== > > > Jon Smirl > > > jon...@ya... > > > > > > > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Win a $20,000 Career Makeover at Yahoo! HotJobs > > http://hotjobs.sweepstakes.yahoo.com/careermakeover > > ===== > Jon Smirl > jon...@ya... > > > > > __________________________________ > Do you Yahoo!? > Win a $20,000 Career Makeover at Yahoo! HotJobs > http://hotjobs.sweepstakes.yahoo.com/careermakeover > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Egbert E. <ei...@su...> - 2004-05-06 08:40:03
|
Jon Smirl writes: > I'm putting together a document for Kernel Summit that describes the issues > around graphics device drivers. The kernel developers are currently making first > pass comments on it. As soon as I fold their comments in I'll post it to > fb-dev, dri-dev and wherever else is appropriate for the next round of comments. > Nobody is proposing final solutions yet, I'm just trying to collect everyone's > opinion. I fear that we will get a very Linux-centric view on device drivers. This will leave us with device drivers for Linux and a different ones (or none!) for the rest of the world. From an X developers point of view this is a support nightmare as he is the first one users will turn to if things don't work as expected. Furthermore I'd argue that as little as necessary should live in the kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. First of all, we will not be able to do generic VESA mode initialization in the kernel (unless we decide to stick a complete x86 emulator into the kernel). Then many driver developers often take a very naive apporach at things and produce code that I know I don't want to see in my kernel. One can try to educate them which may not always be possible - especailly in the case of closed source drivers. Egbert. |
From: Jon S. <jon...@ya...> - 2004-05-06 13:54:11
|
--- Egbert Eich <ei...@su...> wrote: > I fear that we will get a very Linux-centric view on device drivers. > This will leave us with device drivers for Linux and a different ones Tell me the right non-Linux lists and I will post there too. There have been significant complaints from the Linux kernel developers over the current DRM code. Most of it centers around the crossplatform support. Better division of the platform specfic code from the generic code should address these. > kernel space. One thing that - in my opinion - should *not* live in > there is mode detection and initialization. I'm making some progress on this front. I think I've talked benh into it, and he's started talking to Linus about it. If Linux goes this path then is someone going to move the other platforms onto this path too? Support is starting to grow for merging FB/DRM into a simgle driver. --- Benjamin Herrenschmidt <be...@ke...> wrote: > > > The proposal is for a user space library that does mode setting as well as > other > > common things like cursor support. This library would in turn load plug-in > > libraries for each card. > > Ok, we have been discussing all of these points over and over again, and > I will be at KS, so I didn't want to restart the whole thing on this > list, but I wanted to note a few things though: > > > For the mode setting case the library would read the DDC data for each head > > using the existing I2C drivers or the driver plug-in lib for non-standard > cases. > > This data would then be combined with config files where the user can > override > > modelines and such. > > I agree with the idea of moving the EDID decoding & mode selection to > userland. In this regard, though, I beleive we should aim toward some > simple library that sits with the kernel, eventually distributed with > the kernel tree, to live in initramfs optionally since it may be > required to even get a console at boot (which is fine, initramfs is > available early). The video cards themselves have PCI drivers that can > "trigger" detection by the library via hotplug, the library could manage > things like persistant configuration, either separate desktops or > geometry of a complex desktop, etc... and eventually notification of > userland clients of mode changes. > > One reason for that is lots of monitors lie about their capabilities in > their EDID block, so we want "override" files. > > The kernel driver in this case doesn't need to be that much different > than the current fbdev's though, except that we want to move the HW > access for graphics commands to the kernel too, which basically turns > into merging the DRI driver and the fbdev. There is no need, I think, to > re-invent the wheel from scratch here, it would be a lot more realistic > to build on top of those existing pieces. > > > The modelines would be passed into the plug-in libs which would turn them > into > > register values. Finally the plug-in lib would use a private IOCTL to set > the > > state into the video hardware. > > Note that there are side effect. Changing the mode on a head can trigger > a mode change on another. That typically happen when doing things like > mirroring in which case you may want to turn your mirrored screen into a > mode whose aspect ration is compatible with the second screen. > (Typically the case with non-4:3 LCD laptop screens mirroring to 4:3 > CRTs). In general, the thing should be designed so that clients can be > notified at any time of configuration changes. That along with a lower > level arbitration mecanism on actual hardware access. > > > There are numerous pros and cons for both a both schemes. The user space > code is > > swappable, easier to debug, and does not need to be run as root. Cons are > that > > these are more pieces to track. Device driver code is minimized. On the > other > > hand boot time mode setting forces the code back into the kernel. Early > user > > space should also be considered. It may be possible to use the BIOS for > display > > until early user space is there, then change the mode. There's only about a > > screenful of display before early user space starts. > > If the userland code is in initramfs, it can be run very early, we can > use a small text engine like pmac btext for early debugging if > necessary. > > > A side effect of the whole mode setting issue is dual/tri head cards. Once > there > > are multiple heads with multiple framebuffers. FB is going to have to start > mem > > managing the VRAM which it does not currently do. DRI runs a memory manager > over > > the same VRAM and this is a conflict. > > Yes, that, access arbitration, and config change notifications are the > main issues at this time. > > > Another conflict is that the OpenGL/xserver can move the display framebuffer > > around in memory, for example when going full screen on video. It will be > > complicated to coordinate the location of the current scan buffers between > > xserver and fb. Currently Xfree can't do this so it isn't a problem. > > Ben. > > ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: Egbert E. <ei...@pd...> - 2004-05-10 11:47:17
|
Jon Smirl writes: > --- Egbert Eich <ei...@su...> wrote: > > I fear that we will get a very Linux-centric view on device drivers. > > This will leave us with device drivers for Linux and a different ones > > Tell me the right non-Linux lists and I will post there too. There have been > significant complaints from the Linux kernel developers over the current DRM > code. Most of it centers around the crossplatform support. Better division of > the platform specfic code from the generic code should address these. Right. However I've got the impression that this has improved already. As far as DRM is concerned only a few OSes/platforms matter. mode setting and 2D accel is an issue on many more OSes. Many of those don't have a vital community as Linux does. Idnividuals and groups intereseted in X (until now XFree86) on these platforms usually gather on the project related mailing lists. > > > kernel space. One thing that - in my opinion - should *not* live in > > there is mode detection and initialization. > > I'm making some progress on this front. I think I've talked benh into it, and > he's started talking to Linus about it. If Linux goes this path then is someone > going to move the other platforms onto this path too? Support is starting to > grow for merging FB/DRM into a simgle driver. > > --- Benjamin Herrenschmidt <be...@ke...> wrote: > > > > > The proposal is for a user space library that does mode setting as well as > > other > > > common things like cursor support. This library would in turn load plug-in > > > libraries for each card. > > > > Ok, we have been discussing all of these points over and over again, and > > I will be at KS, so I didn't want to restart the whole thing on this > > list, but I wanted to note a few things though: > > > > > For the mode setting case the library would read the DDC data for each head > > > using the existing I2C drivers or the driver plug-in lib for non-standard > > cases. > > > This data would then be combined with config files where the user can > > override > > > modelines and such. Most of this exists inside of X already. These pieces could easily be separated out of the server. > > > > I agree with the idea of moving the EDID decoding & mode selection to > > userland. In this regard, though, I beleive we should aim toward some I don't only want to see mode selection in user land but also mode programming. I keep reiterating the reasons: 1. Mode programming for a number of chips needs to be done thru the BIOS. Unless one wants to stick a complete x86 emulator into the kernel this needs to be done from user land. 2. HW programming (especially programming around hw quirks) is a hard job, and you need the hardware - if possible every flavor if it. No need to duplicate this for different OSes - not speaking of the support nightmare that is involved. 3. Quality of video driver code is often not what we expect from kernel code. The focus of the developer is often clearly upon getting the hardware to work. Graphics driver programmers shouldn't be forced to have to deal with kernel interfaces. 4. Debugging mode setting code involves a lot of round trips (edit->build-> test->edit...). This can be done more effectively from user space. 5. Having this code in user mode in a separate project allows deployment of support for new chipsets. > > simple library that sits with the kernel, eventually distributed with > > the kernel tree, to live in initramfs optionally since it may be > > required to even get a console at boot (which is fine, initramfs is > > available early). The video cards themselves have PCI drivers that can > > "trigger" detection by the library via hotplug, the library could manage > > things like persistant configuration, either separate desktops or > > geometry of a complex desktop, etc... and eventually notification of > > userland clients of mode changes. There are competing requirements here: Libs that wack the hardware should be OS/platform independent as possible. This is also a license issue. Yes, we will most likely need OS dependent non-chipset specific wrappers, but those are cheap to do - a lot cheaper than code dealing directly with chipset quirks. > > > > One reason for that is lots of monitors lie about their capabilities in > > their EDID block, so we want "override" files. > > > > The kernel driver in this case doesn't need to be that much different > > than the current fbdev's though, except that we want to move the HW > > access for graphics commands to the kernel too, which basically turns > > into merging the DRI driver and the fbdev. There is no need, I think, to > > re-invent the wheel from scratch here, it would be a lot more realistic > > to build on top of those existing pieces. > > > > > The modelines would be passed into the plug-in libs which would turn them > > into > > > register values. Finally the plug-in lib would use a private IOCTL to set > > the > > > state into the video hardware. It's not that easy. Modelines are only one part of the picture and - with the advent of different display output technologies there are a lot of other things that play a role here. Egbert. |
From: David B. <dbr...@li...> - 2004-05-10 18:11:44
|
Egbert Eich wrote: >I don't only want to see mode selection in user land but also mode >programming. >I keep reiterating the reasons: > >1. Mode programming for a number of chips needs to be done thru the BIOS. > Unless one wants to stick a complete x86 emulator into the kernel > this needs to be done from user land. >2. HW programming (especially programming around hw quirks) is a hard job, > and you need the hardware - if possible every flavor if it. > No need to duplicate this for different OSes - not speaking of the support > nightmare that is involved. > > I don't know if someone else has suggested this (if so, I apologize for stealing your idea, random person), but is there any reason you can't have the more complicated mode programming code (the non-bootstrap variety) as a userspace program which the kernel somehow "calls" (however it ends up; via FIFO communication, whatever; I'm not a kernel guru), and which does all the mode setting work? As I see it, this'd basically get around all the license problems with the mode setting code (it could still be GPL, yet since it isn't in a position to taint, that's OK) and it would result in -one- location, guaranteed, for mode setting code. I don't know whether the one location thing'd be a good idea, but it sounds like one to me. It'd ensure that the mode setting code was -entirely- separate from the X server, any other libraries, etc. It'd also allow the driver writer, at their discretion, to put the code in the kernel (in which case the userspace code would never be used) or in userspace (in which case the kernel would simply request that the userspace code do its bidding). You could simply pass something like this (using an arbitrary text format) to userspace: radeon:1024x768 and have it set the best-match mode. The 'radeon' part, of course, would make sure that the wrong code wasn't used. Likewise, the userspace program could be fed any data it needed this way. Anyhow, just an idea. No idea if it's a good one or not, really; but I'd love to hear feedback. David Bronaugh |
From: David B. <dbr...@li...> - 2004-05-10 18:31:29
|
David Bronaugh wrote: > > You could simply pass something like this (using an arbitrary text > format) to userspace: > > radeon:1024x768 > > and have it set the best-match mode. The 'radeon' part, of course, > would make sure that the wrong code wasn't used. Likewise, the > userspace program could be fed any data it needed this way. Clarification here: I said something which didn't cover the ground very well. You'd probably want something more like radeon;pci:0000:01:01.1;1024x768 You'd want to identify which subdevice of which card was involved. I don't know how far this would go, but without identifying the specific device, it'd be pretty useless. David Bronaugh |
From: Egbert E. <ei...@pd...> - 2004-05-11 17:02:30
|
David Bronaugh writes: > Egbert Eich wrote: > > >I don't only want to see mode selection in user land but also mode > >programming. > >I keep reiterating the reasons: > > > >1. Mode programming for a number of chips needs to be done thru the BIOS. > > Unless one wants to stick a complete x86 emulator into the kernel > > this needs to be done from user land. > >2. HW programming (especially programming around hw quirks) is a hard job, > > and you need the hardware - if possible every flavor if it. > > No need to duplicate this for different OSes - not speaking of the support > > nightmare that is involved. > > > > > I don't know if someone else has suggested this (if so, I apologize for > stealing your idea, random person), but is there any reason you can't > have the more complicated mode programming code (the non-bootstrap > variety) as a userspace program which the kernel somehow "calls" > (however it ends up; via FIFO communication, whatever; I'm not a kernel > guru), and which does all the mode setting work? I don't think you want to call user mode code from inside the kernel. The kernel could take a passive role and use the mode that a userland program tells it is set. If all the kernel needs is a linear freambuffer of size x * y and depth d there is no problem. Things get a little more complicated if the kernel wants to set the fb start address for scrolling, use acceleration for faster drawing or the framebuffer is not really fully linear. > > As I see it, this'd basically get around all the license problems with > the mode setting code (it could still be GPL, yet since it isn't in a > position to taint, that's OK) and it would result in -one- location, > guaranteed, for mode setting code. I don't know whether the one location > thing'd be a good idea, but it sounds like one to me. Here my point is that the world is not Linux only (although I use Linux myself) and it would make sense to make this code portable across OSes. In this case GPL may be a problem - especially if the code needs to go into the kernel. > > It'd ensure that the mode setting code was -entirely- separate from the > X server, any other libraries, etc. It'd also allow the driver writer, > at their discretion, to put the code in the kernel (in which case the > userspace code would never be used) or in userspace (in which case the > kernel would simply request that the userspace code do its bidding). You mean code that could be put either into the kernel or live in userland - depending on the requirements of the underlying OS? > > You could simply pass something like this (using an arbitrary text > format) to userspace: > > radeon:1024x768 > > and have it set the best-match mode. The 'radeon' part, of course, would > make sure that the wrong code wasn't used. Likewise, the userspace > program could be fed any data it needed this way. > Right, however there are people who like to have a more fine grained control over things than just accepting what the driver considers the best-match. Cheers, Egbert. |
From: David B. <dbr...@li...> - 2004-05-11 18:53:40
|
Egbert Eich wrote: >David Bronaugh writes: > > Egbert Eich wrote: > > > > >I don't only want to see mode selection in user land but also mode > > >programming. > > >I keep reiterating the reasons: > > > > > >1. Mode programming for a number of chips needs to be done thru the BIOS. > > > Unless one wants to stick a complete x86 emulator into the kernel > > > this needs to be done from user land. > > >2. HW programming (especially programming around hw quirks) is a hard job, > > > and you need the hardware - if possible every flavor if it. > > > No need to duplicate this for different OSes - not speaking of the support > > > nightmare that is involved. > > > > > > > > I don't know if someone else has suggested this (if so, I apologize for > > stealing your idea, random person), but is there any reason you can't > > have the more complicated mode programming code (the non-bootstrap > > variety) as a userspace program which the kernel somehow "calls" > > (however it ends up; via FIFO communication, whatever; I'm not a kernel > > guru), and which does all the mode setting work? > >I don't think you want to call user mode code from inside the kernel. >The kernel could take a passive role and use the mode that a userland >program tells it is set. If all the kernel needs is a linear freambuffer >of size x * y and depth d there is no problem. >Things get a little more complicated if the kernel wants to set the fb >start address for scrolling, use acceleration for faster drawing or the >framebuffer is not really fully linear. > > I was talking about the userspace code -only- doing mode setting. It would take the parameters passed to it via a FIFO or whatever, in whatever format, and set that mode on the specified device. Nothing more. It wouldn't have state (if at all possible). One thing I'm not at all sure about is how to have bidirectional communication between kernel and userspace. The idea I had was for the userspace mode-setting program to open a block device-file (like /dev/drmctl0 (just making up names here)) and wait for input in the form of a string (there's no reason to go with the formats I've suggested here; they're just for the sake of argument). On receipt of that input, it would either set the requested mode and tell the kernel exactly what mode it set, or not set the requested mode and tell the kernel it didn't set the mode (both via the same device-file; maybe an ioctl?). > > As I see it, this'd basically get around all the license problems with > > the mode setting code (it could still be GPL, yet since it isn't in a > > position to taint, that's OK) and it would result in -one- location, > > guaranteed, for mode setting code. I don't know whether the one location > > thing'd be a good idea, but it sounds like one to me. > >Here my point is that the world is not Linux only (although I use Linux >myself) and it would make sense to make this code portable across OSes. >In this case GPL may be a problem - especially if the code needs to >go into the kernel. > > The userspace mode-setting program (what I'm talking about here), which would be doing any more tricky mode setting, would have -no- hooks into the kernel. None. Thus, even if it were GPL, it wouldn't be a problem for it to be running on a *BSD. > > It'd ensure that the mode setting code was -entirely- separate from the > > X server, any other libraries, etc. It'd also allow the driver writer, > > at their discretion, to put the code in the kernel (in which case the > > userspace code would never be used) or in userspace (in which case the > > kernel would simply request that the userspace code do its bidding). > >You mean code that could be put either into the kernel or live in userland >- depending on the requirements of the underlying OS? > > Or the requirements of the hardware, or the decisions of the driver creator -- whichever. Of course, the kernel portion would potentially still have license problems... it's not a total solution to that. But -- it does get as much code as you want into userspace, without enforcing policies. > > You could simply pass something like this (using an arbitrary text > > format) to userspace: > > > > radeon:1024x768 > > > > and have it set the best-match mode. The 'radeon' part, of course, would > > make sure that the wrong code wasn't used. Likewise, the userspace > > program could be fed any data it needed this way. > > > >Right, however there are people who like to have a more fine grained >control over things than just accepting what the driver considers the >best-match. > > Right... what this says to me is that there have to be more possible parameters in this string. For instance, maybe something like: - radeon;pci:0000:01:10.1;1024x768@75hz;linear for a linear framebuffer with a refresh rate of 75hz at 1024x768 on the Radeon at pci:0000:01:10.1 - radeon;pci:0000:01:10.0;TV for TV-mode on the first function of the same Radeon - i830;pci:0000:01:10.0;1152x864;tiled4k for 4kb tiles on an i830 (total guesswork; but iirc that's what i8xx uses) Just ideas. Feedback entirely welcome :) David Bronaugh |
From: Egbert E. <ei...@pd...> - 2004-05-12 14:07:35
|
David Bronaugh writes: > Egbert Eich wrote: > > > >I don't think you want to call user mode code from inside the kernel. > >The kernel could take a passive role and use the mode that a userland > >program tells it is set. If all the kernel needs is a linear freambuffer > >of size x * y and depth d there is no problem. > >Things get a little more complicated if the kernel wants to set the fb > >start address for scrolling, use acceleration for faster drawing or the > >framebuffer is not really fully linear. > > > > > I was talking about the userspace code -only- doing mode setting. It > would take the parameters passed to it via a FIFO or whatever, in > whatever format, and set that mode on the specified device. Nothing more. > > It wouldn't have state (if at all possible). > > One thing I'm not at all sure about is how to have bidirectional > communication between kernel and userspace. The idea I had was for the > userspace mode-setting program to open a block device-file (like > /dev/drmctl0 (just making up names here)) and wait for input in the form > of a string (there's no reason to go with the formats I've suggested > here; they're just for the sake of argument). On receipt of that input, > it would either set the requested mode and tell the kernel exactly what > mode it set, or not set the requested mode and tell the kernel it didn't > set the mode (both via the same device-file; maybe an ioctl?). That is pretty much like power management is handled today. A user daemon sits there and waits for events. It will act accordingly and return a status to the kernel. But why do you want to do mode setting from inside the kernel anyhow? If we can make the kernel do its output on whatever video mode it gets we should be fine. This way the user app sets the video mode and the kernel can still print emergency messages (well, in theory - as writing to the fb will definitely collide with active accellerator hardware). And the initial mode setting for boot messages needs to happen way earlier - possibly in a bootstrap manager. > > > > As I see it, this'd basically get around all the license problems with > > > the mode setting code (it could still be GPL, yet since it isn't in a > > > position to taint, that's OK) and it would result in -one- location, > > > guaranteed, for mode setting code. I don't know whether the one location > > > thing'd be a good idea, but it sounds like one to me. > > > >Here my point is that the world is not Linux only (although I use Linux > >myself) and it would make sense to make this code portable across OSes. > >In this case GPL may be a problem - especially if the code needs to > >go into the kernel. > > > > > The userspace mode-setting program (what I'm talking about here), which > would be doing any more tricky mode setting, would have -no- hooks into > the kernel. None. Thus, even if it were GPL, it wouldn't be a problem > for it to be running on a *BSD. > > > > It'd ensure that the mode setting code was -entirely- separate from the > > > X server, any other libraries, etc. It'd also allow the driver writer, > > > at their discretion, to put the code in the kernel (in which case the > > > userspace code would never be used) or in userspace (in which case the > > > kernel would simply request that the userspace code do its bidding). > > > >You mean code that could be put either into the kernel or live in userland > >- depending on the requirements of the underlying OS? > > > > > Or the requirements of the hardware, or the decisions of the driver > creator -- whichever. > > Of course, the kernel portion would potentially still have license > problems... it's not a total solution to that. But -- it does get as > much code as you want into userspace, without enforcing policies. > Right. > > > >Right, however there are people who like to have a more fine grained > >control over things than just accepting what the driver considers the > >best-match. > > > > > Right... what this says to me is that there have to be more possible > parameters in this string. > And some may even be driver dependent. Egbert. |
From: David B. <dbr...@li...> - 2004-05-13 07:25:27
|
Egbert Eich wrote: >David Bronaugh writes: > > Egbert Eich wrote: > > > > > >I don't think you want to call user mode code from inside the kernel. > > >The kernel could take a passive role and use the mode that a userland > > >program tells it is set. If all the kernel needs is a linear freambuffer > > >of size x * y and depth d there is no problem. > > >Things get a little more complicated if the kernel wants to set the fb > > >start address for scrolling, use acceleration for faster drawing or the > > >framebuffer is not really fully linear. > > > > > > > > I was talking about the userspace code -only- doing mode setting. It > > would take the parameters passed to it via a FIFO or whatever, in > > whatever format, and set that mode on the specified device. Nothing more. > > > > It wouldn't have state (if at all possible). > > > > One thing I'm not at all sure about is how to have bidirectional > > communication between kernel and userspace. The idea I had was for the > > userspace mode-setting program to open a block device-file (like > > /dev/drmctl0 (just making up names here)) and wait for input in the form > > of a string (there's no reason to go with the formats I've suggested > > here; they're just for the sake of argument). On receipt of that input, > > it would either set the requested mode and tell the kernel exactly what > > mode it set, or not set the requested mode and tell the kernel it didn't > > set the mode (both via the same device-file; maybe an ioctl?). > >That is pretty much like power management is handled today. >A user daemon sits there and waits for events. It will act >accordingly and return a status to the kernel. >But why do you want to do mode setting from inside the kernel >anyhow? If we can make the kernel do its output on whatever video >mode it gets we should be fine. This way the user app sets the >video mode and the kernel can still print emergency messages >(well, in theory - as writing to the fb will definitely collide with >active accellerator hardware). > > My only argument for having any of the mode setting kernel-side, really, was for bootstrap/initial mode setting. Other than that, I don't care. >And the initial mode setting for boot messages needs to happen way >earlier - possibly in a bootstrap manager. > > > > > > > As I see it, this'd basically get around all the license problems with > > > > the mode setting code (it could still be GPL, yet since it isn't in a > > > > position to taint, that's OK) and it would result in -one- location, > > > > guaranteed, for mode setting code. I don't know whether the one location > > > > thing'd be a good idea, but it sounds like one to me. > > > > > >Here my point is that the world is not Linux only (although I use Linux > > >myself) and it would make sense to make this code portable across OSes. > > >In this case GPL may be a problem - especially if the code needs to > > >go into the kernel. > > > > > > > > The userspace mode-setting program (what I'm talking about here), which > > would be doing any more tricky mode setting, would have -no- hooks into > > the kernel. None. Thus, even if it were GPL, it wouldn't be a problem > > for it to be running on a *BSD. > > > > > > It'd ensure that the mode setting code was -entirely- separate from the > > > > X server, any other libraries, etc. It'd also allow the driver writer, > > > > at their discretion, to put the code in the kernel (in which case the > > > > userspace code would never be used) or in userspace (in which case the > > > > kernel would simply request that the userspace code do its bidding). > > > > > >You mean code that could be put either into the kernel or live in userland > > >- depending on the requirements of the underlying OS? > > > > > > > > Or the requirements of the hardware, or the decisions of the driver > > creator -- whichever. > > > > Of course, the kernel portion would potentially still have license > > problems... it's not a total solution to that. But -- it does get as > > much code as you want into userspace, without enforcing policies. > > > >Right. > > If this proposal were to follow your idea, and encompass all mode setting code, then the only code needed -should- be trivial. In fact (interesting idea) there's no reason a userspace application couldn't feed a mode change request to the daemon via a FIFO, and the mode setter merely inform the kernel (sounds a bit more sane, even). That would almost totally decouple mode setting from the kernel -- which, by the sounds of it, would be a good thing. If an OS wants to do things differently, it shouldn't be a big deal. > > > > > >Right, however there are people who like to have a more fine grained > > >control over things than just accepting what the driver considers the > > >best-match. > > > > > > > > Right... what this says to me is that there have to be more possible > > parameters in this string. > > > >And some may even be driver dependent. > > Absolutely. Anyhow... to recap the ideas thus far: - Userspace application (mode setter) which holds all mode setting code which waits on a FIFO for input - Informs kernel of mode changes via ioctl - Small userspace library to format mode requests to be sent to the mode setter via FIFO - Kernel video device manager (for lack of a better term) handles ioctl informing kernel of mode changes Does this sound good? Also, should I be forwarding this onto other lists, etc? David Bronaugh |
From: David B. <dbr...@li...> - 2004-05-13 08:04:36
|
David Bronaugh wrote: > Anyhow... to recap the ideas thus far: I'm going to elaborate considerably at this point, probably dragging in lots of stuff no one wants to see in here, etc -- all to try and figure out what's wanted/needed. The following is about the mode setter itself. One weird thought I had was that in the end, this "mode setting" system would probably have to handle monitor hotplug events. I don't know how useful this feature is, etc. I'm not sure exactly how this would work, or -if- it works, or if it belongs in this. But -- there are some interesting consequences of it: - Monitors could be unplugged at any time, and swapped -- and things like refresh rates could be changed if needed (an interesting possibility). I'm not sure, but I -think- this might be good support infrastructure for various power management suspend options. - This would allow for monitor swaps during operating system operation to be rather painless, which I can state for certain is not true on some other platforms *cough* Winders *cough* Putting monitor parameter read code (DDC or whatever it ends up being) into this -does- make sense in my opinion (hotplug or none). Feedback on why this is a good/bad thing to do would be nice, since I really don't know. Another weird idea I had involved Linux's hotplug system -- there are some interesting possibilities there. I'm not sure where it'd go though. But -- the end result of it is that there should be more than one way to get output out of this code when a mode change is requested, or other events happen (like monitors being plugged in). Possibly have a message bus to throw stuff like this onto (D-Bus anyone?). This might be useful for a future X server, for example, to be able to change configuration on the fly as the hardware configuration changes. Random question: How close a correspondence is there currently between userspace (X server) and kernelspace (fbdev) drivers? - Userspace application (mode setter) which holds all mode setting code which waits on a FIFO for input - Informs kernel of mode changes (and other things? what else?) via ioctl - Informs other listening applications of mode changes, monitor connect events, etc. (D-Bus?) - (What about hotplug video?) - How should the kernel inform this of a video card addition? Is this meaningful/relevant? - Should call ioctl to get list of available "Extended DRM" devices and associated drivers (don't want to duplicate code) - It seems like there would be exact pairing between kernel-side "Extended DRM" devs and mode setting drivers - This sounds to me like a very useful thing for the "Extended DRM" being proposed (could be used in X servers, maybe; see random question above) - Small userspace library to format mode requests to be sent to the mode setter via FIFO - Don't reinvent the wheel - Format of messages might be something like device identifier, resx, resy, colour depth, refresh (optional), extra_params (optional) - Kernel "Extended DRM" driver (for lack of a better term) handles ioctl informing kernel of mode changes Anyhow, there's the weird-thoughts-and-fleshing-out for the day. David Bronaugh |
From: Mike M. <che...@ya...> - 2004-05-13 09:16:13
|
--- David Bronaugh <dbr...@li...> wrote: > - Format of messages might be something like device identifier, > resx, resy, colour depth, refresh (optional), extra_params (optional) Did you talk at all about memory mngmt? For instance when setting a mode is it needed to have a frame buffer or at least enuff memory for that mode. The reason I ask is in the VGA days one could have 6 FBs. I know for most things 2 will be sufficent but 3 is also good, thought it's true you probly rarely need a full-screen FB. > - Kernel "Extended DRM" driver (for lack of a better term) handles ioctl > > informing kernel of mode changes > > Anyhow, there's the weird-thoughts-and-fleshing-out for the day. > > David Bronaugh > __________________________________ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 |
From: David B. <dbr...@li...> - 2004-05-13 17:36:12
|
Mike Mestnik wrote: >--- David Bronaugh <dbr...@li...> wrote: > > >> - Format of messages might be something like device identifier, >>resx, resy, colour depth, refresh (optional), extra_params (optional) >> >> >Did you talk at all about memory mngmt? For instance when setting a mode >is it needed to have a frame buffer or at least enuff memory for that >mode. The reason I ask is in the VGA days one could have 6 FBs. I know >for most things 2 will be sufficent but 3 is also good, thought it's true >you probly rarely need a full-screen FB. > > I didn't talk at all about memory management -- I guess I should, because obviously that ground's not covered. First, you'd have to add a parameter specifying how many framebuffers you wanted at that res -- add that after 'depth'. Next, you'd use a kernel-side ioctl to query whether there is enough memory to set a mode -- almost identical to the ioctl to actually set the mode. So the sequence would go: - Userspace program requets mode by feeding string into FIFO of mode setter (generated using library) - Mode setter makes sure that the mode is possible given the current monitor setup and CRTC - Mode setter locks device (so that nothing funny can happen) - Mode setter asks kernel if mode is possible - If mode is not possible, mode setter releases lock and feeds "couldn't do this" type response to program requesting mode - If mode is possible, continue - Mode setter tries to set mode - If somehow this fails, mode setter releases lock and feeds "couldn't do this" type response to program requesting mode - I don't know how this would ever happen; if it can't this code can be simplified. - If this succeeds, continue - Mode setter informs kernel of mode change, new parameters - Mode setter releases lock If the actual act of setting a mode can never fail, then this can be simplified -- we don't need an ioctl to ask if a mode is possible (from the kernel's perspective; aka, is there enough memory), we simply need a way to find out if setting that mode in kernel was successful. Essentially, this would be the set of events then: - Userspace program requets mode by feeding string into FIFO of mode setter (generated using library) - Mode setter makes sure that the mode is possible given the current monitor setup and CRTC - Mode setter locks device (so that nothing funny can happen) - Mode setter informs kernel of mode change, new parameters - If mode is not possible, mode setter releases lock and feeds "couldn't do this" type response to program requesting mode - If mode is possible, continue - Mode setter sets mode - Mode setter releases lock When the mode setter informs the kernel of a mode change, it can do whatever it wants, but the logical action is for it to allocate framebuffer memory. This is one possible route, where the kernel is minimally involved. I don't like it all that much, for the following reasons: - It's illogical to open a FIFO which ends in some userspace program to set modes (shouldn't you call an ioctl to the driver to do this?) The alternative is to have the kernel somehow call this code (can it feed a FIFO?). I don't know if this is a better approach -- Egbert Eich doesn't seem to think so. Feedback more than weclome. David Bronaugh |
From: Mike M. <che...@ya...> - 2004-05-13 18:45:54
|
This is vary good. - To accomidate mergedfb the number of FBs should be allowed to be 0. - Sharing of FBs should be allowed, for heads on the same card. - There is no way to ?change?(read as specify) the size of a FB. - Allocating the second/... FB may be difficult, - Have mem free as well as mem total. - Returning hardware capabilitys(like in a termcap type way), not just mem sizes. I.E. zbuffer type(how to know it's size). --- David Bronaugh <dbr...@li...> wrote: > Mike Mestnik wrote: > > >--- David Bronaugh <dbr...@li...> wrote: > > > > > >> - Format of messages might be something like device identifier, > >>resx, resy, colour depth, refresh (optional), extra_params (optional) > >> > >> > >Did you talk at all about memory mngmt? For instance when setting a > mode > >is it needed to have a frame buffer or at least enuff memory for that > >mode. The reason I ask is in the VGA days one could have 6 FBs. I > know > >for most things 2 will be sufficent but 3 is also good, thought it's > true > >you probly rarely need a full-screen FB. > > > > > I didn't talk at all about memory management -- I guess I should, > because obviously that ground's not covered. > > First, you'd have to add a parameter specifying how many framebuffers > you wanted at that res -- add that after 'depth'. > > Next, you'd use a kernel-side ioctl to query whether there is enough > memory to set a mode -- almost identical to the ioctl to actually set > the mode. So the sequence would go: > > - Userspace program requets mode by feeding string into FIFO of mode > setter (generated using library) > - Mode setter makes sure that the mode is possible given the current > monitor setup and CRTC > - Mode setter locks device (so that nothing funny can happen) > - Mode setter asks kernel if mode is possible > - If mode is not possible, mode setter releases lock and feeds > "couldn't do this" type response to program requesting mode > - If mode is possible, continue > - Mode setter tries to set mode > - If somehow this fails, mode setter releases lock and feeds > "couldn't do this" type response to program requesting mode > - I don't know how this would ever happen; if it can't this code > can be simplified. > - If this succeeds, continue > - Mode setter informs kernel of mode change, new parameters > - Mode setter releases lock > > If the actual act of setting a mode can never fail, then this can be > simplified -- we don't need an ioctl to ask if a mode is possible (from > the kernel's perspective; aka, is there enough memory), we simply need a > > way to find out if setting that mode in kernel was successful. > > Essentially, this would be the set of events then: > > - Userspace program requets mode by feeding string into FIFO of mode > setter (generated using library) > - Mode setter makes sure that the mode is possible given the current > monitor setup and CRTC > - Mode setter locks device (so that nothing funny can happen) > - Mode setter informs kernel of mode change, new parameters > - If mode is not possible, mode setter releases lock and feeds > "couldn't do this" type response to program requesting mode > - If mode is possible, continue > - Mode setter sets mode > - Mode setter releases lock > > When the mode setter informs the kernel of a mode change, it can do > whatever it wants, but the logical action is for it to allocate > framebuffer memory. > > This is one possible route, where the kernel is minimally involved. I > don't like it all that much, for the following reasons: > - It's illogical to open a FIFO which ends in some userspace program to > > set modes (shouldn't you call an ioctl to the driver to do this?) > > The alternative is to have the kernel somehow call this code (can it > feed a FIFO?). I don't know if this is a better approach -- Egbert Eich > doesn't seem to think so. > > Feedback more than weclome. > > David Bronaugh > __________________________________ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 |
From: David B. <dbr...@li...> - 2004-05-14 21:05:35
|
Mike Mestnik wrote: >This is vary good. > - To accomidate mergedfb the number of FBs should be allowed to be 0. > > How does mergedfb work internally? I don't know. Alternatively to this, maybe the best way to do this would be to specify a double-width mode (eg 2048x768) and an extra "feature" parameter of MERGEDFB or some such -- that might work. However, I can't claim to understand mergedfb (as in, how it's implemented) yet, so this is probably a naive solution. > - Sharing of FBs should be allowed, for heads on the same card. > > Same deal, except instead of a "feature" of MERGEDFB, the "feature" should be CLONE > - There is no way to ?change?(read as specify) the size of a FB. > > If you can specify the resolution, you can specify the size of the framebuffer. What else did you have in mind? > - Allocating the second/... FB may be difficult, > - Have mem free as well as mem total. > - Returning hardware capabilitys(like in a termcap type way), not just >mem sizes. I.E. zbuffer type(how to know it's size). > > Hmm... I'd love for you to elaborate here, though I -think- I know what you're getting at. The more I think about this, the more sense it makes to have the apps talking to the kernel and requesting things via ioctl(s), the kernel communicating with the userspace to do "mode management", and the kernel communicating back to the app. Having the being the thing communicated with is getting to be a huge mess. That being said, having kernel calling userspace via whatever method can be ugly. Here's the suggestion I got from hpa (which is roughly what I was thinking of; but he filled in some important bits): - At startup, a pipe is opened which the mode manager can read from and the kernel can write to - When the kernel needs to set a mode, it locks the dev, feeds the pipe, and waits a predefined period of time (0.5s?) - Once the kernel's sure it can set the mode, it feeds the pipe to the mode manager a serialized version of the mode params - The mode manager sets the mode, then goes back to waiting on the pipe - The kernel returns from the ioctl 0.5s (or however much time) after it called the mode manager Bad things about this approach: - Can't tell if setting the mode succeeded (see below about "fail-over") - There is an assumption made about how long it will take to set modes -- would probably have to run with realtime priority to ensure setting the mode happened quickly enough (it already runs as root; why not) Dubious things: - Have to have mode knowledge gleaned from DDC or whatnot in kernel - Alternative: Have also do - There might be problems if the entire device needed to be locked while the mode was being set - My question: Is this necessary? Good things: - Don't have to have the know about MergedFB, clone mode, etc because it's *simply* setting mode timings -- nothing more - Still moves that important chunk of code out of the kernel - Keeps locking entirely in kernel (if it is needed) Here's the call chain for the mode manager (when it starts up): - Sets up pipe to kernel - Tries each DRM device, and finds out what's at each one - Opens a config file, loads in user-specified modelines (necessary?) - Queries each of them for DDC data or whatnot (using the specific driver) and stores it associated with that device - Calls an ioctl on each "live" DRM device and informs it of the available modes (simply xres, yres, refresh; nothing more) - Could fire up a thread to watch for i2c data or whatever - Waits on the pipe Here's my current call chain for setting a mode: - App requests mode from "Extended DRM" via ioctl (same sort of format, except packed into a struct instead of a string) - "Extended DRM" checks if the requested mode is available - "Extended DRM" locks the device - "Extended DRM" checks if there is enough memory to set the specified mode - If not enough memory, "Extended DRM" returns -ENOMEM or something - Otherwise, continue - "Extended DRM" frees previous framebuffer (if applicable), allocates new framebuffer(s) (including Z buffer) - This could be where the device could be unlocked, all depending - If the "Extended DRM" ioctl could have a safe way to set registers, it would be true. - "Extended DRM" cooks up a serialized version of the mode string - "Extended DRM" feeds pipe to userspace application the serialized mode string - "Extended DRM" waits 0.5s or whatever timeout is decided upon - When this is done (if we don't have a safe way to unlock registers and setting modes while other stuff is going on is not safe) the "Extended DRM" unlocks the device - Mode manager receives serialized mode, parses it (or whatever; could simply shove it into a struct; it's trusted code) - Mode manager gets "best-match" mode (you want something usable at least if bad things happen; screen corruption's ugly) - Mode manager sets appropriate registers - Sets timing registers - Does _NOT_ set base address registers or anything to do with tiling modes, or anything of that sort - Is there any reason this restriction cannot be put upon it? - Mode manager goes back to waiting for mode change requests This is sorta what I had in mind for modes. The first part is a blatant rip of linux/fb.h: struct mode { __u32 xres; /* Actual FB width */ __u32 yres; /* Actual FB height */ __u32 xres_virtual; /* Virtual fb width */ __u32 yres_virtual;/* Virtual fb height */ __u32 xoffset; /* Offset of actual from top-left corner of virtual */ __u32 yoffset; __u32 bpp; /* Bits per pixel */ __u32 refresh; /* Preferred refresh rate (0 for no preference) */ __u32 fb_mode; /* Example: various tiled modes versus linear; defined as integers (LINEAR, TILED4K, etc) */ __u32 feature; /* Numeric feature code (eg MERGEDFB, CLONE) */ }; This is what the mode manager receives: struct ms_mode { __u32 xres; __u32 yres; __u32 bpp; __u32 refresh; }; The mode manager then looks this up in its table of modes, and sets the best-match mode. Now at this point, you'll probably be wondering why there isn't a way to say how many framebuffers you have, why you can't specify a Z buffer, etc -- the reason is because fundamentally, setting a mode has nothing to do with double buffering, triple buffering, and 3D graphics -- it's about bootstrapping a usable mode. After the mode's boostrapped, you can do whatever you want with framebuffers -- if you want more buffers, call another ioctl to request them. At least in my opinion, it is not part of mode setting. If you have good reasons why it is, I'd love to hear them. David Bronaugh |
From: Mike M. <che...@ya...> - 2004-05-15 00:44:54
|
Let me start of by saying I think you are on the right track and all of your ideas look good. --- David Bronaugh <dbr...@li...> wrote: > Mike Mestnik wrote: > > >This is vary good. > > - To accomidate mergedfb the number of FBs should be allowed to be 0. > > > > > How does mergedfb work internally? I don't know. > However we need it to? I think if we cripple X the current mergedfb will also have to be crippled. > Alternatively to this, maybe the best way to do this would be to specify > > a double-width mode (eg 2048x768) and an extra "feature" parameter of > MERGEDFB or some such -- that might work. However, I can't claim to > understand mergedfb (as in, how it's implemented) yet, so this is > probably a naive solution. > I see it more as just a way of pointing a viewport to a framebuffer, like a screen(FB) swap. What I see is that a FB gets allocated and then modes get set, with it's viewport looking into this FB. This can all be part of the modesetting code, then the FB and the viewport should be returned. That way the FB can be deallocated, after a succsesfull FB change. There will be rare cases where the card can't handel both FBs then the FB allocate code might need to handel this NEEDED deallocate/change inorder to allocate the new/replacing FB. Hopefully modes can be set withought FBs this cuts down on the FB {a,de}lloc code. However inorder to cutdown on card specific code, it may be best for all cards the deal with worst-case FB alloc, if this is to be a feature. > > - Sharing of FBs should be allowed, for heads on the same card. > > > > > Same deal, except instead of a "feature" of MERGEDFB, the "feature" > should be CLONE > I don't like the idea of having things so static. Attaching and deattaching modes(viewports) from FBs should be done via a full API. If this is at all possible? > > - There is no way to ?change?(read as specify) the size of a FB. > > > > > If you can specify the resolution, you can specify the size of the > framebuffer. What else did you have in mind? > Size of viewport != FB size, thought I think you got that by the end of my msg. > > - Allocating the second/... FB may be difficult, My comments above and below, as two diffrent cases. > > - Have mem free as well as mem total. This helps with multi-tasking, I.E. Two apps sharing the same VT(context). For multi-headed cards thay will have to share FB resources. > > - Returning hardware capabilitys(like in a termcap type way), not > just > >mem sizes. I.E. zbuffer type(how to know it's size). Allocating a FB on some cards may not be a simple as L*H*D. As I'm not an expert on hardware I don't know what snags you might hit on, that are not version but card dependant. > > > > > Hmm... I'd love for you to elaborate here, though I -think- I know what > > you're getting at. > I wish I could but I realy don't know, it's just something I think the desing might need. I used the source and saw into the future. > > This is sorta what I had in mind for modes. The first part is a blatant > rip of linux/fb.h: > > struct mode { > __u32 xres; /* Actual FB width */ > __u32 yres; /* Actual FB height */ > __u32 xres_virtual; /* Virtual fb width */ > __u32 yres_virtual;/* Virtual fb height */ > __u32 xoffset; /* Offset of actual from top-left corner of virtual > */ > __u32 yoffset; > > __u32 bpp; /* Bits per pixel */ > > __u32 refresh; /* Preferred refresh rate (0 for no preference) */ > > __u32 fb_mode; /* Example: various tiled modes versus linear; > defined as integers (LINEAR, TILED4K, etc) */ > __u32 feature; /* Numeric feature code (eg MERGEDFB, CLONE) */ > }; > Virtual fb vs Actual FB. IMHO Actual FB is the monitors mode and not the allocated size of the FB(Virtual fb). > This is what the mode manager receives: > > struct ms_mode { > __u32 xres; > __u32 yres; > __u32 bpp; > __u32 refresh; > }; > No FB? This may be positive. __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ |
From: David B. <dbr...@li...> - 2004-05-15 06:34:37
|
Mike Mestnik wrote: >Let me start of by saying I think you are on the right track and all of >your ideas look good. > >--- David Bronaugh <dbr...@li...> wrote: > > >>Mike Mestnik wrote: >> >> >> >>>This is vary good. >>> - To accomidate mergedfb the number of FBs should be allowed to be 0. >>> >>> >>> >>> >>How does mergedfb work internally? I don't know. >> >> >However we need it to? I think if we cripple X the current mergedfb will >also have to be crippled. > > I think this design allows for mergedfb to work "however we need it to" by encapsulating all that (setup) logic within the "Extended DRM" module. Do you disagree? >>Alternatively to this, maybe the best way to do this would be to specify >> >>a double-width mode (eg 2048x768) and an extra "feature" parameter of >>MERGEDFB or some such -- that might work. However, I can't claim to >>understand mergedfb (as in, how it's implemented) yet, so this is >>probably a naive solution. >> >> >> >I see it more as just a way of pointing a viewport to a framebuffer, like >a screen(FB) swap. What I see is that a FB gets allocated and then modes >get set, with it's viewport looking into this FB. This can all be part of >the modesetting code, then the FB and the viewport should be returned. >That way the FB can be deallocated, after a succsesfull FB change. There >will be rare cases where the card can't handel both FBs then the FB >allocate code might need to handel this NEEDED deallocate/change inorder >to allocate the new/replacing FB. > > Hmm, I don't really see any disagreement here. In fact, I think you're filling in useful missing details in my understanding. The framebuffer alloc code will be part of the proposed "Extended DRM" infrastructure -- which I would rather not be part of (beyond what I want to do). >Hopefully modes can be set withought FBs this cuts down on the FB >{a,de}lloc code. However inorder to cutdown on card specific code, it may >be best for all cards the deal with worst-case FB alloc, if this is to be >a feature. > > All allocation of framebuffers will happen within the kernel. None will be requested by the mode manager. >>> - Sharing of FBs should be allowed, for heads on the same card. >>> >>> >>> >>> >>Same deal, except instead of a "feature" of MERGEDFB, the "feature" >>should be CLONE >> >> >> >I don't like the idea of having things so static. Attaching and >deattaching modes(viewports) from FBs should be done via a full API. If >this is at all possible? > > I don't know whether it is or not. I kind of like this kind of simplicity, though -- I think it allows for simply adding numbers if needed, which would be >>> - There is no way to ?change?(read as specify) the size of a FB. >>> >>> >>> >>> >>If you can specify the resolution, you can specify the size of the >>framebuffer. What else did you have in mind? >> >> >> >Size of viewport != FB size, thought I think you got that by the end of my >msg. > > Yeah, I understood that. >>> - Allocating the second/... FB may be difficult, >>> >>> >My comments above and below, as two diffrent cases. > > Shouldn't be a problem. >>> - Have mem free as well as mem total. >>> >>> >This helps with multi-tasking, I.E. Two apps sharing the same VT(context). > For multi-headed cards thay will have to share FB resources. > > > >>> - Returning hardware capabilitys(like in a termcap type way), not >>> >>> >>just >> >> >>>mem sizes. I.E. zbuffer type(how to know it's size). >>> >>> >Allocating a FB on some cards may not be a simple as L*H*D. As I'm not an >expert on hardware I don't know what snags you might hit on, that are not >version but card dependant. > > > >>> >>> >>> >>> >>Hmm... I'd love for you to elaborate here, though I -think- I know what >> >>you're getting at. >> >> >> >I wish I could but I realy don't know, it's just something I think the >desing might need. I used the source and saw into the future. > > OK; elaborate? >Virtual fb vs Actual FB. IMHO Actual FB is the monitors mode and not the >allocated size of the FB(Virtual fb). > > That's the idea. >>This is what the mode manager receives: >> >>struct ms_mode { >> __u32 xres; >> __u32 yres; >> __u32 bpp; >> __u32 refresh; >>}; >> >> >> >No FB? This may be positive. > > I -did- forget to specify the PCI dev, and the CRTC number (screen number, whatever). That should be added to the struct -- maybe something like this: struct ms_mode { char * pci_dev; __u32 crtc_no; __u32 yres; __u32 bpp; __u32 refresh; }; I can't think of any cases where you'd actually -need- to call the video BIOS in order to change the framebuffer pointer or offsets (if this were true, GL would be a nightmare on those cards). Please. I need more feedback here, people. SPEAK! Destroy my ideas! Nitpick until this proposal looks like swiss chese! The more feedback there is, the better it will be. David Bronaugh |
From: Mike M. <che...@ya...> - 2004-05-16 10:49:54
|
--- David Bronaugh <dbr...@li...> wrote: > Mike Mestnik wrote: > >--- David Bronaugh <dbr...@li...> wrote: > > > > > >>Mike Mestnik wrote: > >> > >> > >> > >>>This is vary good. > >>> - To accomidate mergedfb the number of FBs should be allowed to be > 0. > >>> > >>> > >>> > >>> > >>How does mergedfb work internally? I don't know. > >> > >> > >However we need it to? I think if we cripple X the current mergedfb > will > >also have to be crippled. > > > > > I think this design allows for mergedfb to work "however we need it to" > by encapsulating all that (setup) logic within the "Extended DRM" > module. > > Do you disagree? > Yes, I think the mode/dac programing code should be seperat from the frambuffer allocation/mngmnt code. Wather it should live in the DRM is another story, thought It should live kernel side as it workes closely with the hardware. A fue other questions, directed at the memory mngmt ppl. What about 2d only page fliping, ModeX and the like? Where these ever supported outside of libsvga? Are thay rellecs from the past that can die? > >Hopefully modes can be set withought FBs this cuts down on the FB > >{a,de}lloc code. However inorder to cutdown on card specific code, it > may > >be best for all cards the deal with worst-case FB alloc, if this is to > be > >a feature. > > > > > All allocation of framebuffers will happen within the kernel. None will > be requested by the mode manager. > I think this is the best desing, as it gives the app programer lots of freedom. > >>> - Have mem free as well as mem total. > >>> > >>> > >This helps with multi-tasking, I.E. Two apps sharing the same > VT(context). > > For multi-headed cards thay will have to share FB resources. > > > > > > > >>> - Returning hardware capabilitys(like in a termcap type way), not > >>just > >>>mem sizes. I.E. zbuffer type(how to know it's size). > >Allocating a FB on some cards may not be a simple as L*H*D. As I'm not > an > >expert on hardware I don't know what snags you might hit on, that are > not > >version but card dependant. > > > >>Hmm... I'd love for you to elaborate here, though I -think- I know > what > >>you're getting at. > >I wish I could but I realy don't know, it's just something I think the > >desing might need. I used the source and saw into the future. > OK; elaborate? > Allocating a frame buffer may need a FB description header filled out in video memory, taking up some space. The hardware cursor may need to be at a perticular offset, thus making it immposible for a FB to span that offset. I guess that since there are an infinet number of reasons a FB might not be allicatable that it's better of the call to just fail rather then the lib/app trying to guess that it will. So no communication from the driver to the app is needed. > > David Bronaugh > __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ |
From: Ville <sy...@sc...> - 2004-05-16 15:49:23
|
On Sun, May 16, 2004 at 03:49:49AM -0700, Mike Mestnik wrote: >=20 > A fue other questions, directed at the memory mngmt ppl. What about 2d > only page fliping, ModeX and the like? Where these ever supported outs= ide > of libsvga? Are thay rellecs from the past that can die? Page flipping is important. DirectFB uses it a lot. fbdev is almost enoug= h=20 to implement proper page flipping. The only thing missing is getting the=20 current vblank counter from the pan ioctl(). Without that good triple=20 buffering is impossible. And then there is the problem that fbdev doesn't= =20 handle overlays so good triple buffering for overlays is impossible right= =20 now. That is why I'm quite fond of the "feed the kernel complete register= =20 values"-interface. It would work for CRTCs and overlays. Oh and there is no 2D vs. 3D page flipping. --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |