RE: [Linux-fbdev-devel] API prototype doc

[<cw...@so...>]

> This is actually something I've been debating. I originally had mmap in
> there then removed it... obviously there were some remnants left.
> 
> mmap is a different story. It may be a nice feature for applications, but
> it causes a few problems that are very hard to overcome.
> 
> #1) If a client has a mmapped region of video memory and for some reason
> this region is no longer valid, how do you prevent the client from drawing
> there? We don't have some advanced event interface to tell clients how
> to behave, and at any rate relying on the client to do the right thing isn't
> acceptable. When you switch vt's or another client changes the mode...
> the client with the mmapped region has to be altered. The only way to
> do this is to remove the client's map install a zero page fault handler
> to pause the client when it tries to draw, and then add it back when the
> vt returns. This behavior is shady but might be worth it.

yes, in dealing with modern fb, we have had this problem as well (drawing on fb 
and switching to a different sized vt causes crazy behaviour).  perhaps a call 
to see if the context is still valid could be added, which user land 
applications would use to see if they are still allowed to be drawing.  this 
doesnt provide any security though =(  your approach would work in all cases, 
but would be difficult to manage.

> #2) Not all memory regions are memory mappable. Most of the modes on Intel
> hardware have a pitch that differs from width. This isn't a huge problem
> since you can easily expose the pitch in the surface view. What about
> when the "extra" memory between the width and pitch is being used for
> something else? There will always be valid reasons why you don't want
> to allow mmap. Therefore a client _has_ to have a read/write fallback
> anyway, the value of mmap gets smaller when you have to write the harder
> read/write code anyway.

oo, are there cases where extra pitch memory is used for things?  the area is 
so broken up and in small chunks that i didnt think any hardware developer 
would use it.  but if intel's do that, i'd imagine there is probably something 
there.  this certainly causes problems i wasn't aware of.
 
> #3) When two clients memory map certain types of memory, bad things could
> happen. What if it is some type of shared memory used for command buffers
> or double buffered registers? Then you have to have some type of locking
> on the memory mapped ranges like the dri does. At that point you have
> given a client the ability to take the lock and keep it...basically
> cooperative multitasking.

perhaps making command buffers not mmapable?  in my (limited) understanding, 
they would function just as well ala read/write ?  locking would also work.  
i've heard of irix doing some kind of command locking or something, to keep it 
clean.

> If you look back at some of my posts you'll find that the reason I became
> concerned about the furture of the framebuffer is that The Intel 810 and
> 815 chipsets have only banked memory when the Gtt isn't used. The way
> to handle this isn't as you stated... to give the client an indication
> that bank switching is necessary, and possibly an interface to switch
> the banks. That is too complicated for the client. With this interface
> there is no need to make the client aware of the banks. The driver can
> always switch the banks on the fly. Mmap is difficult and messy, but
> can be done with page faulting tricks.

i believe watcom and maybe other old dos compilers used page faults to switch 
banks on the fly.  is this possible/safe/reliable in linux?  if so, a manual 
bank switch interface would be useless.  I had considered page faults, but i 
was not sure how kernel handled them.

> Discussed above. I agree, it is a nice feature when it works. If it were
> supported it would just go like this. Try to mmap, if it fails you can't
> have it so try something else. This way all the reasons for mmap failing
> are handled. Not just network.

yes, thats the idea i have been going for (keep mmap in, and if it fails do 
something else). 
 
> Maybe a sysreq type thing. This shouldn't be necessary, it is perfectly
> possible to make an interface from which bad things cannot happen. That was
> one of my goals.

if command buffers can be locked, a severely broken application could cause bad 
things to happen, and not have them unlock properly.  this would probably 
results as a failure in the driver code, as even a crashed user land 
application is capable of cleaning itself up some.  if the interface is indeed 
clean, no sort of sane restore would be necessary.  its all in how reliable the 
drivers are =)
 
> I'm sorry but absolutely not. The basic features of the fb should be
> standard,
> everything else should not. The reason is simple. In order to wrap differing
> functionality of hardware you have to add software. The more complex the
> task
> the more software you need. Take 3d, what about chips without 3d? Are you
> going to implement 3d in software in the kernel? Certainly not. If you
> define
> some bit pattern that indicates if 3d is supported or not, all you've done
> is make the client choose a rendering path based on the driver. If you just
> used a user library in the first place this wouldn't be necessary.
> 
> I think I wasn't clear in my document, but I'll state it here. NOTHING that
> is device specific should ever be touched by a client directly. Only a
> library
> should be touching those features. So in the 3d case the client uses Mesa,
> it links against libGL and doesn't have to worry about anything else. Mesa,
> has a user-space driver which does hardware specific things and dispatches,
> via the driver specific interfaces, to the driver.

Ahh, ok =)  yes, from user-land, they should only see one interface.  I was 
under the impression that the client would have to account for all different 
interfaces. thanks for clearing that up.
 
> I think you have a limited view of a "driver". "Really large" and kernel
> should
> never be mixed. If you want a nice, use anywhere, driver interface for an
> application you need a library of some sort. That is the only good way.
> 

> #2) You make a permissions enhanced driver that can be accessed by
> permissions
> deprived clients with a defined interface. This is the kernel driver model.
> The problem here is that the complexity of the interface, and therefore
> driver code, increases exponentially with each feature added (provided the
> feature isn't exactly the same on all hardware). So your kernel driver gets
> huge quickly, Linux kernel developers wouldn't allow that.
>   There is another option here. Make the kernel driver small but only
> implement
> a subset of available features, forcing the client to do the work. This is
> how the OSS driver work (sound). The client may want 24bit 44k stereo, but
> when the client asks the kernel for it the answer may be NO! In that case
> the client has to do rate conversion to a sound format that IS supported.
> This
> is all fine and good except that now you have made ALL clients responsible
> for rate conversion, most will do it badly, some not at all.

> #3) Implement this rule: "Get as close to the hardware format as is SAFELY
> possible in user-space then to the rest in the kernel". This is the model
> I was looking to do. To take the sound example above this would mean that
> a sound library queries the sound driver to determine the supported formats
> at startup. The client tells the library 24bit 44k stereo and the library
> then determines that this isn't possible and converts without the clients
> knowledge. The "driver" does the work, just as you wanted. But "driver"
> does not mean kernel-space.
>   Why not do the whole thing in user-space? (XFree?) Because not everything
> can be done that way. You cannot have correct device virtualization,
> locking,
> etc. You also force all clients to use the single API you have provided. In
> the split model you can have several libraries implementing different API's
> without redoing the lowest level hardware drivers. These only have to be
> done
> once and all clients, XFree, DRI, Directfb etc. can use them.
>   One more point here. By standardizing the very basic parts of the API you
> allow clients to use these features without the overhead of a library. Mode
> setting, basic drawing etc. Very basic features that can be wrapped with
> minimal code complexity that have obvious gains by being standard.

ahh, ok.  i was visualizing a combination of #2 and #3 (#1 is bad for any kind 
of modern non/embedded system).

i dont know what i was thinking there.  sorry about that last part.  libraries 
are indeed better in that situation.

i suppose the idea was to provide a sufficiently diverse interface to the 
libraries that are going to be implimenting the acceleration, but that seems 
mostly, if not completely, done already.

thanks for the enlightening view of the driver/kernel-land/library model =)

chris

--- moc.lexiptfos@thgirwc ---