James,
Attached is a patch hopefully to improve/fix the current framebuffer
framework. The patch is quite massive, so I'll enumerate the changes:
1. Resource allocation
Allocation of fbcon resources will be acquired on a per device
(fb_info) basis. This includes data for the cursor, the cursor
timer/vbl irq handler, the scrollback buffer, and optionally the pixmap
buffer. The justification for these changes may not be obvious right
now (since only 1 console is active at a time), but it should at least
make it ready for the future when multiple active consoles are to be
supported
2. Console mapping
a. fb_console_init
The current method of determining which framebuffer should be mapped to
the console on initialization is incorrect for 2.5 (it's okay for 2.4)
because of the separation and modularity of fbcon/fbdev. It currently
uses registered_fb[num_registered_fb-1]. This is incorrect if the user
does something like this:
modprobe firstfb; modprobe secondfb; rmmod firstfb; modprobe fbcon
So, it now searches for the first valid framebuffer in registered_fb[]
instead.
b. set_con2fb_map
There are numerous problems with this. The first one is related to
2.a. The second one is it uses take_over_console(). The problem with
this method is that it will call fbcon_startup() several times. (In 2.4
fbcon_startup is called only once). Since it is in fbcon_startup where
resources are allocated, doing set_con2fb_map more than once will cause
resource leaks (cursor timer, info->display_fg, etc).
The change is to deallocate all acquired resources when a particular
framebuffer is not mapped anymore to any of the console. Basically,
fbdev will be dissociated from fbcon.
Thirdly, the code will not work, due to various reasons, if fbcon is
compiled as a module. This is also fixed.
set_con2fb_map should now work if fbcon is compiled statically or as a
module, and fbcon will also load correctly even when there is no
registered framebuffer. The user can then use con2fbmap later on.
3. Forced register updates
This may be useful in cases when switching from a tty where X is
currently active. It basically checks for vt_cons[con]->vt_pid. If
this value is valid, it means a process has installed its own VT, so
switching from that tty will be "untrusted". fb_set_var will force an
fb_set_par whether var has changed or not
4. Minor fixes to scrolling and fbcon_resize
The test done in fbcon_resize is now more liberal. This is congruent
with Geert's accel_clear_margins() fix. Also, scrollback_phys_max and
p->vrows are now updated on time in hope of fixing some panning glitches
5. Minor fixes in fbmon.c
The functions fb_get_mode and fb_validate_mode should now also consider
the dotclock, besides hsync and vsync.
6. Reference counting of buffer usage inf accel_putcs
Reference counting is done for fb_pixmap->addr, hopefully to improve
concurrency even more.
7. Cosmetic changes
All kernel parameters are standardized to [driver]fb. Also fixed
affected docs in Documentation/fb/*.
The diff is against 2.5.64 + fbdev.diff.gz (Mar 6 23:58).
Tony
|
