summaryrefslogtreecommitdiff
path: root/drivers/video/console/vgacon.c
AgeCommit message (Collapse)Author
2005-11-22[PATCH] vgacon: Fix usage of stale height value on vc initializationAntonino A. Daplas
Reported by: Wayne E. Harlan "[1.] One line summary of the problem: When the kernel option "vga=1" is used, additional tty's (alt+control+Fx with x=2,3,4,5, etc) do not provide the full 50 lines of output. The first one does have 50 lines, however. [2.] Full description of the problem/report: These addtitional tty's show only 39 lines plus the top pixel of the 40-th line. The remaining lines are black and not shown. Kernel version 2.6.13.4 does not show this problem." This bug is caused by using a stale font height value on vgacon_init. Booting with vga=1 gives an 80x50 screen with an 8x8 font. Somewhere during the initialization, the font was changed to 8x9 and the first vc was correctly resized to 80x44. However, the rest of the vc's were not allocated yet, and when they were subsequently initialized, they still used a font height of 8 (instead of 9) causing the mentioned bug. Fix by saving the new font height to vga_video_font_height. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-05[PATCH] Set the vga cursor even when hiddenSamuel Thibault
Some visually impaired people use hardware devices which directly read the vga screen. When newt for instance asks to hide the cursor for better visual aspect, the kernel puts the vga cursor out of the screen, so that the cursor position can't be read by the hardware device. This is a great loss for such people. Here is a patch which uses the same technique as CUR_NONE for hiding the cursor while still moving it. Mario, you should apply it to the speakup kernel for access floppies asap. I'll submit a 2.4 patch too. Signed-off-by: samuel.thibault@ens-lyon.org Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30[PATCH] fix vgacon blankingPozsar Balazs
This patch fixes a long-standing vgacon bug: characters with the bright bit set were left on the screen and not blacked out. All I did was that I lookuped up some examples on the net about setting the vga palette, and added the call missing from the linux kernel, but included in all other ones. It works for me. You can test this by writing something with the bright set to the console, for example: echo -e "\e[1;31mhello there\e[0m" and then wait for the console to blank itself (by default, after 10 mins of inactivity), maybe making it faster using setterm -blank 1 so you only have to wait 1 minute. Signed-off-by: Pozsar Balazs <pozsy@uhulinux.hu> Cc: James Simmons <jsimmons@infradead.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-17[PATCH] SVGATextMode fixSamuel Thibault
Fix bug 5441. I didn't know about messy programs like svgatextmode... Couldn't this be integrated in some linux/drivers/video/console/svgacon.c ?... So because of the existence of the svgatextmode program, the kernel is not supposed to touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ? Disabling the check in vgacon_resize() might help indeed, but I'm really not sure whether it will work for any chipset: in my patch, CRT registers are set at each console switch, since stty rows/cols apply to consoles separately... The attached solution is to keep the test, but if it fails, we assume that the caller knows what it does (i.e. it is svgatextmode) and then disable any further call to vgacon_doresize. Svgatextmode is usually used to _expand_ the display, not to shrink it. And it is harmless in the case of a too big stty rows/cols: the display will just be cropped. I tested it on my laptop, and it works fine with svgatextmode. A better solution would be that svgatextmode explicitely tells the kernel not to care about video timing, but for this an interface needs be defined and svgatextmode be patched. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-15[PATCH] vgacon: Fix sanity checking in vgacon_resizeAntonino A. Daplas
Reported by: walt <wa1ter@myrealbox.com> "I routinely switch the console font during bootup to 8x8 so I can get 50 lines per screen. Until 09 Sept, just changing to the small font automatically gave me all 50 lines -- but now I'm only getting 25 lines even with the small font. The bottom half of the screen displays the text that already scrolled off the top." This bug is due to an erroneous check in the recently added hook, vgacon_resize(). It checks the new height against the original number of rows of the console. Because the original number of rows depends on both the scanline and the font height, check it instead against the scanline/fontheight. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09[PATCH] vga text console and stty cols/rowsSamuel Thibault
Some people use 66-cells braille devices for reading the console, and hence would like to reduce the width of the screen by using: stty cols 66 However, the vga text console doesn't behave correctly: the 14 first characters of the second line are put on the right of the first line and so forth. Here is a patch to correct that. It corrects the disp_end and offset registers of the vga board on console resize and console switch. On usual screens, you then correctly get a right and/or bottom blank margin. On some laptop panels, the output is resized so that text actually gets magnified, which can be great for some people (see http://dept-info.labri.fr/~thibault/ls.jpg ). Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21[PATCH] VGA to fbcon fix.James Simmons
Currently when going from vgacon to fbcon the VT screenbuffer are often different sizes. In the case when they are different sizes a new VT screenbuffer is allocated and the contents are copied into the new buffer. Currently the amount copied from VGA text memory to the new screenbuf is the size of the framebuffer console. If the framebuffer console new VT screen buffer is greater than the VGA text memory size then we get some of the VGA BIOS contents as well. This patch will only allow you to copy up to the size of VGA text memory now. The rest is filled with erase characters. Initial patch by Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: James Simmons <jsimmons@www.infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] vgacon: set vc_hi_font_mask correctlyBill Nottingham
When allocating a new VC with vgacon_init(), the font is shared across all the VGA consoles. However, the font mask was always set to the default value of zero in visual_init(), even if we were using 512 character fonts at the time. Moreover, code in vgacon.c:vga_do_font_op() didn't reset the mask if the console driver thinks it's already in 512 character mode. This means that to *fix* it, you'd actually have to take the console out of 512 character mode and then set it back. The attached sets vc_hi_font_mask in vgacon_init() for any new consoles opened if the vgacon driver is already in 512 character mode, solving this. This bug goes back to 2.4.18 at least, probably earlier. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!