|
From: Antonino D. <ad...@po...> - 2003-03-07 16:03:31
|
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 |