Sorry, don't seem to have Petr's mail here.
James Simmons writes:
> On Tue, 16 May 2000, Petr Vandrovec wrote:
> > On 16 May 00 at 22:25, Geert Uytterhoeven wrote:
> > > BTW, drivers that conform to the new API can have fb_ops->fb_get_{var,fix,cmap}
> > > == NULL as well, if fbmem.c takes care of that.
Petr,
James' new API changes absolutely *no* external API features. I can swear
by this, because I have changed my fbcon driver already to the new internal
API.
The situation is basically this:
1. fb_get_var()
old: The old API always passed the "con" argument with the value of the
currently active console to fb_get_var. This means that
FBIO_GET_VSCREENINFO returns the *currently displayed* VT size.
new: The new API ignores the "con" argument and simply returns the
*currently displayed* VT size.
Therefore, there is no change in user API or functionality of this change
what so ever.
2. fb_get_fix()
same as above
3. fb_get_cmap()
same as above
Therefore, in total, James' internal API cleanup has absolutely *no* externally
visible changes.
For instance, with the new API, I can still have /dev/tty1 at 800x600, 8bpp,
tty2 at 1024x768, 24bpp, and /dev/tty7 at 1280x1024 16bpp. I can switch
between them, and the hardware gets updated correctly. To prove it:
[root@sturm rmk]# chvt 1;fbset 640x480-60;chvt 2;fbset 800x600-60 -depth 16;chvt 1;fbset;chvt 2;fbset
mode "name"
# D: 25.175 MHz, H: 31.469 kHz, V: 59.940 Hz
geometry 640 480 640 480 8
timings 39722 48 16 33 10 96 2
endmode
mode "name"
# D: 40.000 MHz, H: 37.879 kHz, V: 60.317 Hz
geometry 800 600 800 600 15
timings 25000 88 40 23 1 128 4
hsync high
vsync high
endmode
[root@sturm rmk]#
As you can see from the above example, tty1 is 640x480, 8bpp. tty2 is 800x600,
15bpp. I can set both consoles independently. I can read both consoles
independently. Again, this is with the James' new API.
This is the old behaviour with the old internal API. This is the new
behaviour with the new internal API. Therefore, old behaviour is the same
as the new behaviour. The API may have changed, but the functionality
hasn't.
> > Unfortunately, James is still working from wrong end of problem :-(
I don't believe he is.
> > Instead of first creating layer in fbcon which handles different videomodes
> > on different VTs and then removing this code from lowlevel drivers,
> > he instead first removes this code from drivers (making them very limited,
> > I'm glad that he skipped matroxfb) and then, maybe, he'll write fbcon
> > layer.
We already have the required fbcon layer to implement the new API. I'm
already using it. It works. I don't see your problem.
James' update is a well welcome cleanup that I publically appaud James for
doing. Its certainly made the API much much clearer and more logical, and
removed duplicated code.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:15 EST