Re: r269471 make unusable VT console
Hi, I just update my box. I confirm too that r270322 fixed the problem. Thanks for fix it, -- Carlos Jacobo Puga Medina c...@fbsd.es ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
On 19.08.2014 18:28, Jean-Sébastien Pédron wrote: Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch This is now in HEAD, as of r270322. Again, this is unfinished work, but it already brings improvements. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
On 22 August 2014 01:47, Jean-Sébastien Pédron jean-sebastien.ped...@dumbbell.fr wrote: On 19.08.2014 18:28, Jean-Sébastien Pédron wrote: Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch This is now in HEAD, as of r270322. Again, this is unfinished work, but it already brings improvements. Woo! Thanks! -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
On 16.08.2014 01:51, Nathan Whitehorn wrote: It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to be reverted. Just a quick note: I'm working on an update to vt_vga. The current patch already fixes the draw speed problem, but I'm not finished yet (the mouse cursor is broken as well as some other small annoyances). -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 19.08.2014 10:42, Jean-Sébastien Pédron wrote: On 16.08.2014 01:51, Nathan Whitehorn wrote: It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to be reverted. Just a quick note: I'm working on an update to vt_vga. Hello! Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch What's new/fixed: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). With all this information at hand, it can redraw the dirty area with almost no read from the video memory. This greatly improves the performance. The implementation is quite naive and I put a lot of comments. This could probably be simplfied/improved. The cursor is drawn at the same time than the text: this avoids flickering of the mouse pointer. The patch reads from the video memory only when the byte to write uses more than 2 colors (fg/bg). But this only happens with colored text around the cursor or with fonts who's width isn't a multiple of 8. o In vt_flush(), handle the cursor position before getting the dirty area. This fixes a bug where, if we move the cursor too fast, its new location is outside the marked area and it disappears from the screen. While here, mark the new position of the cursor as dirty, not only the old one. For the cursor to be drawn, VWF_MOUSE_HIDE must not be set *and* VDF_MOUSECURSOR must be set! Before, only the former was checked when deciding if the cursor position should be marked as dirty. Finally, if the cursor didn't move, don't mark its position as dirty. Before, these two problems caused major redraw of a large part of the screen for nothing, due to a mouse pointer location of [0;0] (even if disabled) and its position always marked as dirty. o When the mouse state is changed, mark its position as dirty. o The flush timer is paused during a window switch. In the case of vt_vga, vga_initialize() is called and it messes with VGA registers and the video memory. If vt_flush() is triggered at the same time, unexpected data are displayed. This is fixed, though, there's still a annoying flickering, because the sync signal is temporarily stopped during vga_initialize(). o The patch includes another non-related patch, which tries to stabilize the refresh rate. Currently, we schedule the next redraw in 40 ms (25 Hz), but that doesn't count for the time taken to redraw. o Change how the mouse is enabled/disabled/shown/hidden. Now, the GETLEVEL and GETMODE ioctls don't touch this. Everything goes through the CONS_MOUSECTL ioctl. This fixes vidcontrol -m on|off. Known issues: o Instead of having an if (bitblt_text != NULL) check in vt_flush(), I'll add a generic bitblt_text callback which implements the old code, so that other drivers can be changed incrementally. o In vt_vga, the screen flickers during a window switch, because it stops the sync signal and zeroes the memory. It would be nice to avoid that. o Several issues when the font is changed: 1. The offset to center the text area is global, not per window. Therefore other window are not centered anymore. 2. There's a bug with my patch, where other windows have the top-left letter wrongly shifted. 3. When the text area changes (compared to the whole screen), there's garbage in the borders. 4. The text cursor (the square) may be broken on other windows. o The mouse pointer is somtimes not erased during a move. o The text square cursor handling in vt_vga could be improved: colors are just reversed, we shouldn't change the fg/bg colors, just write a 0x00 pattern instead. o The vt_flush() timer could maybe be stopped when there's nothing to draw. No need to wakeup a core for that. Any comments? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 08/19/14 09:28, Jean-Sébastien Pédron wrote: On 19.08.2014 10:42, Jean-Sébastien Pédron wrote: On 16.08.2014 01:51, Nathan Whitehorn wrote: It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to be reverted. Just a quick note: I'm working on an update to vt_vga. Hello! Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch Thanks! What's new/fixed: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). With all this information at hand, it can redraw the dirty area with almost no read from the video memory. This greatly improves the performance. The implementation is quite naive and I put a lot of comments. This could probably be simplfied/improved. The cursor is drawn at the same time than the text: this avoids flickering of the mouse pointer. The patch reads from the video memory only when the byte to write uses more than 2 colors (fg/bg). But this only happens with colored text around the cursor or with fonts who's width isn't a multiple of 8. Why is this necessary? I'd really prefer to avoid complicating this API. One of the great things about writing newcons drivers is that there is basically only one function you need to implement. If the current API does not provide enough information to do this efficiently, I'd much rather change it than add new callbacks. -Nathan o In vt_flush(), handle the cursor position before getting the dirty area. This fixes a bug where, if we move the cursor too fast, its new location is outside the marked area and it disappears from the screen. While here, mark the new position of the cursor as dirty, not only the old one. For the cursor to be drawn, VWF_MOUSE_HIDE must not be set *and* VDF_MOUSECURSOR must be set! Before, only the former was checked when deciding if the cursor position should be marked as dirty. Finally, if the cursor didn't move, don't mark its position as dirty. Before, these two problems caused major redraw of a large part of the screen for nothing, due to a mouse pointer location of [0;0] (even if disabled) and its position always marked as dirty. o When the mouse state is changed, mark its position as dirty. o The flush timer is paused during a window switch. In the case of vt_vga, vga_initialize() is called and it messes with VGA registers and the video memory. If vt_flush() is triggered at the same time, unexpected data are displayed. This is fixed, though, there's still a annoying flickering, because the sync signal is temporarily stopped during vga_initialize(). o The patch includes another non-related patch, which tries to stabilize the refresh rate. Currently, we schedule the next redraw in 40 ms (25 Hz), but that doesn't count for the time taken to redraw. o Change how the mouse is enabled/disabled/shown/hidden. Now, the GETLEVEL and GETMODE ioctls don't touch this. Everything goes through the CONS_MOUSECTL ioctl. This fixes vidcontrol -m on|off. Known issues: o Instead of having an if (bitblt_text != NULL) check in vt_flush(), I'll add a generic bitblt_text callback which implements the old code, so that other drivers can be changed incrementally. o In vt_vga, the screen flickers during a window switch, because it stops the sync signal and zeroes the memory. It would be nice to avoid that. o Several issues when the font is changed: 1. The offset to center the text area is global, not per window. Therefore other window are not centered anymore. 2. There's a bug with my patch, where other windows have the top-left letter wrongly shifted. 3. When the text area changes (compared to the whole screen), there's garbage in the borders. 4. The text cursor (the square) may be broken on other windows. o The mouse pointer is somtimes not erased during a move. o The text square cursor handling in vt_vga could be improved: colors are just reversed, we shouldn't change the fg/bg colors, just write a 0x00 pattern instead. o The vt_flush() timer could maybe be stopped when there's nothing to draw. No need to wakeup a core for that. Any comments? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
On 19.08.2014 19:46, Nathan Whitehorn wrote: On 08/19/14 09:28, Jean-Sébastien Pédron wrote: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). Why is this necessary? I'd really prefer to avoid complicating this API. One of the great things about writing newcons drivers is that there is basically only one function you need to implement. If the current API does not provide enough information to do this efficiently, I'd much rather change it than add new callbacks. I don't want to have two callbacks for the same feature either, and I'd like to transition other drivers to this new one. The current bitbltchr callback only knows about one character. In the case of vt_vga, if this character (or the cursor) isn't aligned on 8-pixels boundaries, it needs to redraw several blocks of pixels. With this character-centric approach, if a block needs a redraw, it'll be refreshed for the character on its left side, then refreshed again for the character on its right side. The advantage of giving the callback the whole text/area is that it allows the driver to manipulate the pixels block by block, instead of character by character. The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I made (especially the cursor handling in vt_flush()). But eventually, the plan is to convert all drivers to this new callback, if you find the new API sensible. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
On 19.08.2014 21:20, Adrian Chadd wrote: Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? I read a lot about VGA in the past days but I'm new to this interface, so my reasonning may be wrong. Anyway, here it is: To write a group of 8 pixels with only 2 colors, I write a byte using background color in an offscreen memory, read it back to load it in the latches, put the foreground color in the Set/Reset register, then write the character/cursor to its final location in video memory. Because the background color almost never changes, only one read is made the first time we load the background color, and then only writes. This is fast. If the group of 8 pixels uses 3 or more colors, I can't use Write Mode 3 alone. I see two possibilities: 1. Set Write Mode 0, then for each plane, compute the byte to write (1 bit out of 4 of each pixel's color), activate one plane, write the byte (repeat for each plane), restore Write Mode 3 and the relevant registers. 2. Stay in Write Mode 3, do a read/write for each colors. The first solution has a constant time of execution. The second one depends on the number of colors. In the end, I guess both solutions are expensive, but hopefully are rarely used. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 08/19/14 12:02, Jean-Sébastien Pédron wrote: On 19.08.2014 19:46, Nathan Whitehorn wrote: On 08/19/14 09:28, Jean-Sébastien Pédron wrote: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). Why is this necessary? I'd really prefer to avoid complicating this API. One of the great things about writing newcons drivers is that there is basically only one function you need to implement. If the current API does not provide enough information to do this efficiently, I'd much rather change it than add new callbacks. I don't want to have two callbacks for the same feature either, and I'd like to transition other drivers to this new one. The current bitbltchr callback only knows about one character. In the case of vt_vga, if this character (or the cursor) isn't aligned on 8-pixels boundaries, it needs to redraw several blocks of pixels. With this character-centric approach, if a block needs a redraw, it'll be refreshed for the character on its left side, then refreshed again for the character on its right side. The advantage of giving the callback the whole text/area is that it allows the driver to manipulate the pixels block by block, instead of character by character. The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I made (especially the cursor handling in vt_flush()). But eventually, the plan is to convert all drivers to this new callback, if you find the new API sensible. That sounds great. There are only a few (3?) discrete implementations of bitbltchr in the tree right now, so the conversion should be easy. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
Hi, On 19 August 2014 12:40, Jean-Sébastien Pédron dumbb...@freebsd.org wrote: On 19.08.2014 21:20, Adrian Chadd wrote: Hey, this is cool! So hm, why are you still doing any reading? Don't you now have all the information you need to write out the font and cursor information for each given set of 8 pixels? I read a lot about VGA in the past days but I'm new to this interface, so my reasonning may be wrong. Anyway, here it is: To write a group of 8 pixels with only 2 colors, I write a byte using background color in an offscreen memory, read it back to load it in the latches, put the foreground color in the Set/Reset register, then write the character/cursor to its final location in video memory. Because the background color almost never changes, only one read is made the first time we load the background color, and then only writes. This is fast. If the group of 8 pixels uses 3 or more colors, I can't use Write Mode 3 alone. I see two possibilities: 1. Set Write Mode 0, then for each plane, compute the byte to write (1 bit out of 4 of each pixel's color), activate one plane, write the byte (repeat for each plane), restore Write Mode 3 and the relevant registers. Yup. That's how I've done it in the past. There's no read required and computing that stuff on modern CPUs is really cheap. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
On Tue, 12 Aug 2014 23:28:07 +0200 Carlos Jacobo Puga Medina c...@fbsd.es wrote: I believe it's still broken. There's a related PR at http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would you mind reverting this reversion? It seems to have created a lot of problems. -Nathan Yes, I think that ray@ is around here somewhere to fix this :P Regards, -- Carlos Jacobo Puga Medina c...@fbsd.es Hi guys! Sorry for delay. Carlos, can you please share picture of such bad behaviuor? Looks like this mode almost unused novadays, so modern hardware have problems in implementations of this mode. Thanks! WBW -- Aleksandr Rybalko r...@ddteam.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
keep in mind that the vt_vga code will be used for new VGA bring-up on hardware that exposes legacy VGA bits and pieces, at least until EFI booting is guaranteed everywhere. Trying to do development on the console of something using the current vt_vga in order to bring up things like an ethernet driver will be .. special. -a On 15 August 2014 15:14, Aleksandr Rybalko r...@ddteam.net wrote: On Tue, 12 Aug 2014 23:28:07 +0200 Carlos Jacobo Puga Medina c...@fbsd.es wrote: I believe it's still broken. There's a related PR at http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would you mind reverting this reversion? It seems to have created a lot of problems. -Nathan Yes, I think that ray@ is around here somewhere to fix this :P Regards, -- Carlos Jacobo Puga Medina c...@fbsd.es Hi guys! Sorry for delay. Carlos, can you please share picture of such bad behaviuor? Looks like this mode almost unused novadays, so modern hardware have problems in implementations of this mode. Thanks! WBW -- Aleksandr Rybalko r...@ddteam.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
It also has bad effects on boot time. My desktop takes something like 3 times as long to boot after r269471. If it can't be fixed quickly, it needs to be reverted. -Nathan On 08/15/14 15:27, Adrian Chadd wrote: keep in mind that the vt_vga code will be used for new VGA bring-up on hardware that exposes legacy VGA bits and pieces, at least until EFI booting is guaranteed everywhere. Trying to do development on the console of something using the current vt_vga in order to bring up things like an ethernet driver will be .. special. -a On 15 August 2014 15:14, Aleksandr Rybalko r...@ddteam.net wrote: On Tue, 12 Aug 2014 23:28:07 +0200 Carlos Jacobo Puga Medina c...@fbsd.es wrote: I believe it's still broken. There's a related PR at http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would you mind reverting this reversion? It seems to have created a lot of problems. -Nathan Yes, I think that ray@ is around here somewhere to fix this :P Regards, -- Carlos Jacobo Puga Medina c...@fbsd.es Hi guys! Sorry for delay. Carlos, can you please share picture of such bad behaviuor? Looks like this mode almost unused novadays, so modern hardware have problems in implementations of this mode. Thanks! WBW -- Aleksandr Rybalko r...@ddteam.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r269471 make unusable VT console
I believe it's still broken. There's a related PR at http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would you mind reverting this reversion? It seems to have created a lot of problems. -Nathan Yes, I think that ray@ is around here somewhere to fix this :P Regards, -- Carlos Jacobo Puga Medina c...@fbsd.es ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
