Some questions

[Thomas Winischhofer <thomas@winischhofer.net>]

I am currently porting the SiS framebuffer driver to the - more or less
- new API. Better late than never :)

Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
development, no fbdev patches)

1) Sisfb currently does not work if compiled statically into the kernel.
(It works as a module if fbcon is a module, too). If sisfb and fbcon are
the kernel, the mode switch occures but the only thing I see is a white
rectangle at the left egde of the screen, vertically centered, with some
flashing grey dots. I almost looks like text mode output while in
graphics mode, or - better - if fbcon assumes a font size of 1 pixel.
Finally, it seems to oops, but I can't say that for sure because I don't
see anything (and I unfortunately don't have a serial console available).

Can anybody confirm that this (ie both low level driver and fbcon in
kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
implementation)? Did I perhaps miss anything, like a kernel parameter to
activate fbcon or similar?

2) If both sisfb and fbcon are modules, everything works s supposed when
first modprobing sisfb and then fbcon. Upon modprobing fbcon, the mode
switch occures and I see a graphical console (with a white rectangle of
the size of the previous console size which vanishes upon pressing enter).

However, I could not manage to gain a graphical console if sisfb is a
module, but fbcon is in the kernel. Is this combination supposed to
work? If so, how?

3) The resizing using stty is - how do I put this - slightly imperfect.
I don't know how you fbdev folks do it, but I am not used to think in
row/col categories, but *resolutions* instead. Apart from this - IMHO a
bit annoying - inconvenience, this method has further issues:

a) Calculating the desired mode resolution my simply multiplying the
rows/cols by the font size very often results in odd modes like 800x592.
This even when using a standard 8x16 font, not thinking of situations
where for instance 12x22 fonts are used. How is the low level driver
supposed to handle this?

To temporarily overcome this, I implemented a somewhat fuzzy mode
identification routine, searching for modes with resolutions within a
range of [desired res] - [desired res + 16]. But I can't imagine this
being the Real Thing.

b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
but not the call to fbcon_resize() from within fbcon_switch(). This
leads to catastrophic drawing errors if the requested mode is not
supported by the low level driver.

c) fbcon_resize() only changes var.xres and var.yres, leaving everything
else - var.pixclock, for instance - alone. fb_set_var() just calles the
driver's check_var() routine and then set_par(). How is the low level
driver supposed to behave in this situation, especially considering the
unchanged pixclock?

d) Starting with a mode of 1024x768 and resizing to 800x600 using stty
works after all (see a)), but only if I execute stty twice. The desired
mode the low level driver receives at the first attempt is 800x768.
Could this be related to an outdated or buggy stty, calling the console
code twice if rows and cols are specified at the same time...?

3) About y panning: In the 2.4 version of sisfb, I simply forced the
console to do y panning (unless positively disabled by the user) by
"patching" yres_virtual to the maximum, depending on the available video
memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
be believe so...)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf