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

[Sottek, M. J <mat...@in...>]

>hey, it looks nice.  i was kinda expecting something really bad to happen,
with 
>the whole removal of mmap et al.  yet you provided a physical address,
which is 
>a good thing.  hopefully this will be mapable somehow.  (closer reading
shows a 
>xxx_fb_mmap functions.  good deal.)

This is actually something I've been debating. I originally had mmap in
there then removed it... obviously there were some remnants left.

Ioctl needs to go away for network transparency, once you implement the
read/write command functions there is no reason to have ioctl too. The
local case doesn't need to be different than the remote case.

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.

#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.

#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.

>one thing i don't like about the current methods is the lack of partially 
>addressable screens (ie vesa1.2 banks).  it would be nice if somewhere
along 
>the line someone put in an ADDRESSED_BANKED define and then had a size and 
>pointer to the bank.  it woudl make it really helpful when i develop on my
486 
>(i kid you not, its 11 years old and works like a charm).  this is more of
a 
>novelty feature though =)

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.

>overall, it would be nice for an application to know if its connecting to a

>networked device rather than a local one.  I still see no valid reason for
mmap 
>to die in the name of network transparency (every box has a local set of 
>devices, not every box has a network greater than itself).  im not sure of
the 
>internals of this, it may be possible already, and im just beating a dead
horse.

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.

>the text seems to have a small hint at keeping the device stable enough and

>protected from the user to keep things from going bad.  im kinda iffy on
things 
>protecting the user in this respect (sometimes we learn best not by
watching 
>how things work, but how they break), but the feature would be good as
well, 
>depending on the power of the device.  some kind of restore_sane_state
function 
>and corresponding interface would be handy (special key stroke on terminal
8 or 
>a quadruple right mouse click or any kind of event that rarely happens
(other 
>than system reset)).  a configurable sane state would be a nice addition to

>this too =)

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.

>we have seen in many cases where 'device specific' 'features' cause
problems.  
>the stuff here should be all standard

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.

>is cursor now controlled by fb, or console?  (i read of a development to 
>separate these, as the redundancy caused problems etc.  dont recall which
took 
>the cursor though).  

In this design the fb _draws_ the HW cursor if one is present. Otherwise the
client does it. Note that there is no _hot spot_ in my design. This only
has meaning to the client, not the fb.

>finally:  i, personally, would really like to see a large kerenel driver
level 
>integration of hardware acceleration.  this would be rediclously large and 
>complex and everything, but when successfully completed, will allow any
sort of 
>acceleration from any kind of application. 

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.

There are three ways to do a driver but only one good way:
#1) The application writes directly to the hardware. This is how the old DOS
games worked. Today this is not technically feasible it is a terrible
idea. You would have to run all applications with sufficient permission to
directly access hardware. In practice this means no security what-so-ever.

#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.

-Matt