On 18 May 00 at 14:55, Russell King wrote:
> 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.
> 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.
No! old API passes PROC_CONSOLE() to this. And PROC_CONSOLE() uses
'MINOR(current->tty->device) - 1' under normal conditions (if process has tty).
There is big difference between 'MINOR(current->tty->device) - 1' and
'info->display_fg->vc_num' and I do not see any reason why you think that
MINOR(current->tty->device) - 1 == info->display_fg->vc_num...
(if you cannot find it, PROC_CONSOLE() in implemented in
drivers/video/fbcon.c)
> 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.
So this is fatal difference. Please, could you bother at least to test
'(sleep 5; fbset -depth 16) & chvt 5' on clean 2.1.x, 2.2.x or 2.3.x kernel?
It really does not touch tty5 resolution, although you see this on screen
when fb_set_var is invoked. Really! (if driver bothers with 'con' parameter,
that is)
> 2. fb_get_fix()
> same as above
Yes, same as above. Fatal semantic change.
> 3. fb_get_cmap()
> same as above
Dtto.
> Therefore, in total, James' internal API cleanup has absolutely *no* externally
> visible changes.
They are visible.
> 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
> 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.
Unfortunately, with both 2.2.x (2.2.15) and 2.3.x (2.3.99-pre9-pre2) kernels
I get:
mode "800x600-60"
# D: 40.000 MHz, H: 37.879 kHz, V: 60.317 Hz
geometry 800 600 800 600 16
timings 25000 88 40 23 1 128 4
hsync high
vsync high
accel true
rgba 5/11,6/5,5/0,0/0
endmode
mode "800x600-60"
# D: 40.000 MHz, H: 37.879 kHz, V: 60.317 Hz
geometry 800 600 800 600 16
timings 25000 88 40 23 1 128 4
hsync high
vsync high
accel true
rgba 5/11,6/5,5/0,0/0
endmode
because of all fbset commands operated on VT on which I typed whole
'chvt 1; fbset ....; chvt 2; ....' - of course videomode of VT1 and
VT2 was NOT changed. Only videomode of VT3, where I typed this cmdline,
was changed to 800x600.
> 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.
It is not. Please, download fresh kernel from ftp.xx.kernel.org and
try it with some safe driver.
> > > 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.
It does not... PROC_CONSOLE does NOT return current foreground console,
but tty of that process. Unless you are running fbset from process which
is not attached to tty, such as if you run fbset remote - in that case
it will control currently visible VT. But only in this case. And at least
I do run fbset locally, not remote.
Petr Vandrovec
vandrove@vc.cvut.cz
-
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