> >> Can't it print the oops on whatever is currently displayed?
> >>
> >> It need not be a dedicated buffer as long as there is always some buffer.
> >>
> >> But perhaps this is more complex than that.
> >
> > Yes it is very complex. Reading the code and drm specs you come to
> > realize buffer handling is done with GEM, TTM, or for older drivers
> > drm_maps.
> > Drivers often handle a combine of those, meaning no real wrapper from one
> > api to another :-( From the code it appears GEM is the main userland
> > interface
> > when using KMS. Some how TTM is also usable from userland but I never found
> > a
> > clear example of how that is done. So to the average userland app writer it
> > is
> > a mystery. As for hardware that has a static front buffer I can see how to
> > use drm_maps or TTM but I don't see a easy way to map it to the GEM api.
> > Also their exist ioctl for gem but it appears no one actually uses them
> > but instead write their own :-( So you can see the confusion here.
>
> Userspace buffer management interfaces are pre-driver, the only requirement
> if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS
> drivers
> don't exist for the purposes of fb interaction, so drm_maps are ignorable from
> that pov.
> > Outside of what I described above the drm_framebuffer handling is
> > a mess. From what I can see with the code you can only create a
> > drm_framebuffer with the GEM api. With this case the two most important
> > functions to provide are
>
> This isn't correct. You get a drm_file and a handle, the driver then uses
> these to do whatever it wants to do. This means lookup a GEM object or
> whatever but there is no reliance on GEM or any other memory manager
> outside the driver. Again a handle a file priv are in no way GEM specific.
Searching the TTM code I couldn't find the handle code so easily. I see
that the vmwgfx driver provides a example of using ttm.
> > This gets me to point of where to go from here. We have two choices.
> > The first being we could just make the drm_framebuffer code totally gem
> > dependent thus we could cleanup the drivers code up by moving gem code
> > there. The second option is to make the drm_framebuffer code agnostic to
> > the gem
> > layer. So I have been pondering on how to make the second option work.
> > There is one thing that all these layers do share in common. That is they
> > have some sort of drm_hash with a object lookup. Still pondering how that
> > would be done.
>
> I'm not sure either of these makes sense, can you clearly state the
> goal and maybe we can work out what you need.
Sorry I should of stated what I was planing to do. I like to see drmfb
have the ablitiy to change the resolution via fbset. To do that we need to
be able to create and destory the framebuffer memory if the memory doesn't
fit the size of the new resolution. Plus it gives us the bonus of being
able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem
is that the functions like fb_create are tied to a handle which is not
present for the internal framebuffer used by fbdev. Sorry for the junk
above. It just took me awhile to figure out the code. Their is steep
learning curve. I have patches that should address this coming soon.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
