Menu
▾
▴
linux-fbdev-devel
|
From: Thomas W. <th...@wi...> - 2003-03-05 12:20:55
|
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:th...@wi... http://www.winischhofer.net/ |
|
From: Antonino D. <ad...@po...> - 2003-03-05 13:25:23
|
On Wed, 2003-03-05 at 20:18, Thomas Winischhofer wrote: > 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? Yes, it it does work. > > 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). Ideally, fbdev should only change the video mode on the first fb_open() or fb_set_par() and restore the state on the last fb_close(). This is so you can load fbdev without having a framebuffer console. If memory serves me correctly, that's how sisfb in 2.4 works?. > > 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? No, fbcon will not load unless there's at least one registered fbdev. So, you must compile sisfb statically too. > > 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? Ideally, the driver should round up to the nearest mode it's capable of. The "fraction of a character dimensions" will be automatically cleared by the "clear_margins" hook. > > 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. Yes, that's the Real Thing :-) fbcon_resize has a "fuzzy mode" too -- it won't do an fb_set_var() if the change in dimensions is only a fraction of a character's dimension. > > 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. Yes, it's a bug. I think I submitted a patch to fix that, but I'm not sure if James applied it to his tree. > > 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? > Right, using stty to change the window size assumes that the fbdev driver has an algorithm to calculate modelines based on xres and yres independently. This is probably a bit of work for most driver authors. There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that should ease code writing if you have a VESA GTF compliant monitor. You can use that if you want as long as the display's operating limits are known (info->monspecs). Another solution is to reimplement resizing by fbset. The code is not very difficult and can be added if most people want it. > 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...? Yes, this is a limitation of stty. It calls con_resize twice (one for row and another for cols, depending on the order of the options) so it will not work if the driver only supports a fixed set of modes. Another reason to bring back fbset resizing. > > 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...) Scrolling mode is now determined by fbcon. If var->accel_flag is nonzero, scrolling is ypan, otherwise, it's yredraw. It's because ypan requres a lot of block copy which is slow when done by software. I still believe though that scrolling should be determined by the driver, not fbcon. Tony |
|
From: Geert U. <ge...@li...> - 2003-03-05 14:14:14
|
On 5 Mar 2003, Antonino Daplas wrote:
> > 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?
>
> Ideally, the driver should round up to the nearest mode it's capable
> of. The "fraction of a character dimensions" will be automatically
> cleared by the "clear_margins" hook.
But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, whatever
the font may be.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Thomas W. <th...@wi...> - 2003-03-05 14:21:43
|
Geert Uytterhoeven wrote: >>Ideally, the driver should round up to the nearest mode it's capable >>of. The "fraction of a character dimensions" will be automatically >>cleared by the "clear_margins" hook. > > > But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, > whatever the font may be. Seems the fbdev people themselves aren't really happy with that stty solution...? :) Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Thomas W. <th...@wi...> - 2003-03-05 14:25:16
|
Sorry, but I send mails faster than I can think sometimes: > - and probably is the reason for that vertical offset I see after this > mode switch: The text area on the screen is shifted down by exactly 8 > pixels - 600-592=8 Or perhaps the fbcon_resize stuff does 1) either not take the penguin into account, or 2) does this too early, namely before the call to check_var()? Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: James S. <jsi...@in...> - 2003-03-05 19:03:43
|
> > 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? > > No, fbcon will not load unless there's at least one registered fbdev. > So, you must compile sisfb statically too. I fixed this in my latest patch. You can use con2fb again!!!!!! > > 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. > > Yes, it's a bug. I think I submitted a patch to fix that, but I'm not > sure if James applied it to his tree. Applied. > Another solution is to reimplement resizing by fbset. The code is not > very difficult and can be added if most people want it. :-( > Yes, this is a limitation of stty. It calls con_resize twice (one for > row and another for cols, depending on the order of the options) so it > will not work if the driver only supports a fixed set of modes. Another > reason to bring back fbset resizing. ???? stty rows 128 cols 48 works for me. It should'nt calling con_resize twice. > > 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...) > > Scrolling mode is now determined by fbcon. If var->accel_flag is > nonzero, scrolling is ypan, otherwise, it's yredraw. It's because ypan > requres a lot of block copy which is slow when done by software. > > I still believe though that scrolling should be determined by the > driver, not fbcon. Scrolling needs alot of work. I plan to fix that. |
|
From: Antonino D. <ad...@po...> - 2003-03-06 01:16:55
|
On Thu, 2003-03-06 at 03:02, James Simmons wrote: > > Yes, this is a limitation of stty. It calls con_resize twice (one for > > row and another for cols, depending on the order of the options) so it > > will not work if the driver only supports a fixed set of modes. Another > > reason to bring back fbset resizing. > > ???? stty rows 128 cols 48 works for me. It should'nt calling con_resize > twice. > It does. You probably won't notice it if the driver supports flexible video mode changing. For drivers that don't it will fail. For instance, if a driver supports 800x600 and 1024x768 only, and stty is used to change the mode from 1024x768 to 800x600, it will be done like this: resize to 800x768 <--- because no mode matches this, resizing fails resize to 800x600 If you don't believe me, do an strace stty cols 80 rows 30. Tony |
|
From: Thomas W. <th...@wi...> - 2003-03-05 14:08:56
|
Antonino Daplas wrote: >>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? > > Yes, it it does work. OK, now it works here, too. Seems my debug-printks during initialisation made the kernel go bananas. As soon as I removed them, it walks along... But I noticed another issue here: When switching to gfx mode during boot (ie as soon as the penguin appears), the text console is aligned correctly at all edges, with all lines visible. But when "initial console" starts, the mode is again changed, and now the last line of text is nearly invisible, its upper half appears at the lower screen edge, the lower half is below the screen's edge. The space between the penguin and the text is notably thicker. This can be recovered by switching to another VT and back. This makes the penguin disappear, and restores the console dimensions/edges to normal. Interestingly, this only happens with 800x600; this mode is chosen upon requesting 800x592 (because of the font size). At 1024x768, everything is as it should. >>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? > > No, fbcon will not load unless there's at least one registered fbdev. > So, you must compile sisfb statically too. Then this should definitely go into the kernel config rules, I guess :) >>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? > > Ideally, the driver should round up to the nearest mode it's capable > of. The "fraction of a character dimensions" will be automatically > cleared by the "clear_margins" hook. OK, that's exactly what I do now. I currently tend to the assumption that this mode should be larger than the requested one...? >>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. > > Yes, that's the Real Thing :-) fbcon_resize has a "fuzzy mode" too -- > it won't do an fb_set_var() if the change in dimensions is only a > fraction of a character's dimension. Ack. Is 16 fuzzy enough, what do you think? > Right, using stty to change the window size assumes that the fbdev > driver has an algorithm to calculate modelines based on xres and yres > independently. This is probably a bit of work for most driver authors. Well, not as much work as more a lack of definition. If the user specified a default of 800x600-75 I can't simply assume he also wants 1024x768-75. > There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that > should ease code writing if you have a VESA GTF compliant monitor. You > can use that if you want as long as the display's operating limits are > known (info->monspecs). Well, this assumes that the user always want the best refresh rate, which is not desired in all cases. > Another solution is to reimplement resizing by fbset. The code is not > very difficult and can be added if most people want it. Awaiting public demand :) > Yes, this is a limitation of stty. It calls con_resize twice (one for > row and another for cols, depending on the order of the options) so it > will not work if the driver only supports a fixed set of modes. Another > reason to bring back fbset resizing. Think so, too. That's a really stupid behavior otherwise, since it involves two mode changes, with one really undesired mode on the way. > Scrolling mode is now determined by fbcon. If var->accel_flag is > nonzero, scrolling is ypan, otherwise, it's yredraw. It's because ypan > requres a lot of block copy which is slow when done by software. > > I still believe though that scrolling should be determined by the > driver, not fbcon. Well, what should I do now? The rivafb only forces y panning (ie sets yres_virtual to maximum) if yres_virtual is -1. This is never the case, as default var is constantly reused and I nowhere saw that any of the res_virtuals was set to -1. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Antonino D. <ad...@po...> - 2003-03-05 15:24:34
|
On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote: > >>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? > > > > No, fbcon will not load unless there's at least one registered fbdev. > > So, you must compile sisfb statically too. > > Then this should definitely go into the kernel config rules, I guess :) > I think so, except that fbcon will depend on so many drivers that no one has the patience to add that to Kconfig yet :-) > >>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? > > > > Ideally, the driver should round up to the nearest mode it's capable > > of. The "fraction of a character dimensions" will be automatically > > cleared by the "clear_margins" hook. > > OK, that's exactly what I do now. I currently tend to the assumption > that this mode should be larger than the requested one...? Yes. If it's smaller, it unconditionally calls fb_set_var(), I think. > > >>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. > > > > Yes, that's the Real Thing :-) fbcon_resize has a "fuzzy mode" too -- > > it won't do an fb_set_var() if the change in dimensions is only a > > fraction of a character's dimension. > > Ack. Is 16 fuzzy enough, what do you think? I think you should only accept modes where the difference is a fraction of a character width or height. A difference more than that and clear_margins() will not work correctly. > > > Right, using stty to change the window size assumes that the fbdev > > driver has an algorithm to calculate modelines based on xres and yres > > independently. This is probably a bit of work for most driver authors. > > Well, not as much work as more a lack of definition. If the user > specified a default of 800x600-75 I can't simply assume he also wants > 1024x768-75. > > > There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that > > should ease code writing if you have a VESA GTF compliant monitor. You > > can use that if you want as long as the display's operating limits are > > known (info->monspecs). > > Well, this assumes that the user always want the best refresh rate, > which is not desired in all cases. > fb_get_mode() accepts 4 flags. Maximum refresh rate, hscan-driven, vrefresh-driven and dotclock-driven calculations. It's flexible enough, but of course not as flexible as specifying your own modeline. > > Another solution is to reimplement resizing by fbset. The code is not > > very difficult and can be added if most people want it. > > Awaiting public demand :) > > > Yes, this is a limitation of stty. It calls con_resize twice (one for > > row and another for cols, depending on the order of the options) so it > > will not work if the driver only supports a fixed set of modes. Another > > reason to bring back fbset resizing. > > Think so, too. That's a really stupid behavior otherwise, since it > involves two mode changes, with one really undesired mode on the way. > > > Scrolling mode is now determined by fbcon. If var->accel_flag is > > nonzero, scrolling is ypan, otherwise, it's yredraw. It's because ypan > > requres a lot of block copy which is slow when done by software. > > > > I still believe though that scrolling should be determined by the > > driver, not fbcon. > > Well, what should I do now? > > The rivafb only forces y panning (ie sets yres_virtual to maximum) if > yres_virtual is -1. This is never the case, as default var is constantly > reused and I nowhere saw that any of the res_virtuals was set to -1. > For now, maximize yres_virtual, then set info->var.accel_flag to 1. It wouldn't work until fbset support is reimplemented again, unless you boot directly to that configuration. I'll wait a few more days in hope of hearing from more people before submitting a patch. Tony |
|
From: Thomas W. <th...@wi...> - 2003-03-05 15:40:02
|
Antonino Daplas wrote: >>Ack. Is 16 fuzzy enough, what do you think? > > > I think you should only accept modes where the difference is a fraction > of a character width or height. A difference more than that and > clear_margins() will not work correctly. How do I - from a low level fb driver - determine the character size? >>>I still believe though that scrolling should be determined by the >>>driver, not fbcon. >> >>Well, what should I do now? >> >>The rivafb only forces y panning (ie sets yres_virtual to maximum) if >>yres_virtual is -1. This is never the case, as default var is constantly >>reused and I nowhere saw that any of the res_virtuals was set to -1. >> > > > For now, maximize yres_virtual, then set info->var.accel_flag to 1. That's what I do. (shifted boot screen) >>I am almost sure that this has to do with the fact that I adapt var in >>my check_var from 800x592 to 800x600. Console (or whoever) seems to >>attempt to change the mode to its initially desired dimension on many >>occasions. > > Strange. If you boot at 800x600, the console will compute that as > 100x37. On fbcon_resize, it will request 800x592 but because the > difference is only 8, fb_set_var should be skipped, so no mode change > should happen throughout. But it definitely does. I can see this on my LCD (which goes dark during mode changes) and, of course, the log. > I have no idea. I booted with other drivers at 800x600 and get no ill > effects. I get a margin at the bottom of 8 pixels. > > How about checking what the offsets are during fb_pan_display()? Done that. Nothing special; The penguin is where it should be, but the text below starts 8 lines too low. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Geert U. <ge...@li...> - 2003-03-05 15:46:16
|
On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> >>Ack. Is 16 fuzzy enough, what do you think?
> > I think you should only accept modes where the difference is a fraction
> > of a character width or height. A difference more than that and
> > clear_margins() will not work correctly.
>
> How do I - from a low level fb driver - determine the character size?
You cannot. That's called fbcon-fbdev separation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Thomas W. <th...@wi...> - 2003-03-05 16:02:23
|
Geert Uytterhoeven wrote: > On Wed, 5 Mar 2003, Thomas Winischhofer wrote: > >>Antonino Daplas wrote: >> >>>>Ack. Is 16 fuzzy enough, what do you think? >>> >>>I think you should only accept modes where the difference is a fraction >>>of a character width or height. A difference more than that and >>>clear_margins() will not work correctly. >> >>How do I - from a low level fb driver - determine the character size? > > > You cannot. That's called fbcon-fbdev separation. My question was, basically, meant ironic. But this is funny: You tell me that the difference should not exceed the fraction of a character, but it is impossible to find out how wide/tall characters are. Guys, that won't work. I have to deal with LCD displays and TV output as well (not to say "mainly") and I can't just set up odd modes like 800x592, or mode resolutions based on calculations with any possible odd font dimension. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Geert U. <ge...@li...> - 2003-03-05 16:09:02
|
On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> >>Antonino Daplas wrote:
> >>>>Ack. Is 16 fuzzy enough, what do you think?
> >>>
> >>>I think you should only accept modes where the difference is a fraction
> >>>of a character width or height. A difference more than that and
> >>>clear_margins() will not work correctly.
> >>
> >>How do I - from a low level fb driver - determine the character size?
> >
> >
> > You cannot. That's called fbcon-fbdev separation.
>
> My question was, basically, meant ironic.
>
> But this is funny: You tell me that the difference should not exceed the
> fraction of a character, but it is impossible to find out how wide/tall
> characters are.
>
> Guys, that won't work. I have to deal with LCD displays and TV output as
> well (not to say "mainly") and I can't just set up odd modes like
> 800x592, or mode resolutions based on calculations with any possible odd
> font dimension.
Indeed. That's why fbcon should adapt to fbdev, and not vice versa (IMHO).
I've always been a bit skeptical about the fbcon-driven fbdev-resizing...
I don't mind that you change the resolution or fontsize, but it should not
influence the fbdev too much.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Antonino D. <ad...@po...> - 2003-03-05 16:33:14
|
On Wed, 2003-03-05 at 23:59, Thomas Winischhofer wrote: > Geert Uytterhoeven wrote: > > On Wed, 5 Mar 2003, Thomas Winischhofer wrote: > > > >>Antonino Daplas wrote: > >> > >>>>Ack. Is 16 fuzzy enough, what do you think? > >>> > >>>I think you should only accept modes where the difference is a fraction > >>>of a character width or height. A difference more than that and > >>>clear_margins() will not work correctly. > >> > >>How do I - from a low level fb driver - determine the character size? > > > > > > You cannot. That's called fbcon-fbdev separation. > > My question was, basically, meant ironic. > > But this is funny: You tell me that the difference should not exceed the > fraction of a character, but it is impossible to find out how wide/tall > characters are. > > Guys, that won't work. I have to deal with LCD displays and TV output as > well (not to say "mainly") and I can't just set up odd modes like > 800x592, or mode resolutions based on calculations with any possible odd > font dimension. > Yes, using stty is indeed limited. This was implemented because midway during development, when fbdev was completely separated from fbcon, there was no way to resize the window at all. The first solution was to use stty, better it than none at all. It did confuse a lot of people, especially since not all drivers support changing the resolution without help from the user. Anyway, I have already brought fbset support back in my local copy :-) As I've mentioned, I'll just wait for more replies to the "Feature Freeze?" thread, and I'll submit a test patch. Tony > Thomas > > -- > Thomas Winischhofer > Vienna/Austria > mailto:th...@wi... http://www.winischhofer.net/ > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: Antonino D. <ad...@po...> - 2003-03-05 16:04:51
|
On Wed, 2003-03-05 at 23:37, Thomas Winischhofer wrote: > (shifted boot screen) > >>I am almost sure that this has to do with the fact that I adapt var in > >>my check_var from 800x592 to 800x600. Console (or whoever) seems to > >>attempt to change the mode to its initially desired dimension on many > >>occasions. > > > > Strange. If you boot at 800x600, the console will compute that as > > 100x37. On fbcon_resize, it will request 800x592 but because the > > difference is only 8, fb_set_var should be skipped, so no mode change > > should happen throughout. > > But it definitely does. I can see this on my LCD (which goes dark during > mode changes) and, of course, the log. > > > I have no idea. I booted with other drivers at 800x600 and get no ill > > effects. I get a margin at the bottom of 8 pixels. > > > > How about checking what the offsets are during fb_pan_display()? > > Done that. Nothing special; The penguin is where it should be, but the > text below starts 8 lines too low. > How about removing fbcon_resize() from fbcon_switch()? This should at least give you an idea where the problem is (fbcon_resize, or somewhere else) Tony |
|
From: Geert U. <ge...@li...> - 2003-03-05 15:42:33
|
On 5 Mar 2003, Antonino Daplas wrote:
> On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote:
> > > Yes, that's the Real Thing :-) fbcon_resize has a "fuzzy mode" too --
> > > it won't do an fb_set_var() if the change in dimensions is only a
> > > fraction of a character's dimension.
> >
> > Ack. Is 16 fuzzy enough, what do you think?
>
> I think you should only accept modes where the difference is a fraction
> of a character width or height. A difference more than that and
> clear_margins() will not work correctly.
Indeed, accel_clear_margins() calculates the margins as
unsigned int cw = vc->vc_font.width;
unsigned int ch = vc->vc_font.height;
unsigned int rw = info->var.xres % cw;
unsigned int bh = info->var.yres % ch;
However, if it would use
unsigned int rw = info->var.xres - (vc->vc_cols*cw);
unsigned int bh = info->var.yres - (vc->vc_rows*ch);
it would work with higher differences, too. And it would be a bit faster
(multiply and subtract vs. modulo).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Antonino D. <ad...@po...> - 2003-03-05 15:53:16
|
On Wed, 2003-03-05 at 23:40, Geert Uytterhoeven wrote: > On 5 Mar 2003, Antonino Daplas wrote: > > On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote: > > > > Yes, that's the Real Thing :-) fbcon_resize has a "fuzzy mode" too -- > > > > it won't do an fb_set_var() if the change in dimensions is only a > > > > fraction of a character's dimension. > > > > > > Ack. Is 16 fuzzy enough, what do you think? > > > > I think you should only accept modes where the difference is a fraction > > of a character width or height. A difference more than that and > > clear_margins() will not work correctly. > > Indeed, accel_clear_margins() calculates the margins as > > unsigned int cw = vc->vc_font.width; > unsigned int ch = vc->vc_font.height; > unsigned int rw = info->var.xres % cw; > unsigned int bh = info->var.yres % ch; > > However, if it would use > > unsigned int rw = info->var.xres - (vc->vc_cols*cw); > unsigned int bh = info->var.yres - (vc->vc_rows*ch); > > it would work with higher differences, too. And it would be a bit faster > (multiply and subtract vs. modulo). > Yes, I believe so. This way, it will make rounding off of values more clear cut and still produce an acceptable display (albeit with possibly wider margins). Tony |
|
From: James S. <jsi...@in...> - 2003-03-05 19:32:32
|
> Indeed, accel_clear_margins() calculates the margins as > > unsigned int cw = vc->vc_font.width; > unsigned int ch = vc->vc_font.height; > unsigned int rw = info->var.xres % cw; > unsigned int bh = info->var.yres % ch; > > However, if it would use > > unsigned int rw = info->var.xres - (vc->vc_cols*cw); > unsigned int bh = info->var.yres - (vc->vc_rows*ch); > > it would work with higher differences, too. And it would be a bit faster > (multiply and subtract vs. modulo). Applied. |
|
From: Antonino D. <ad...@po...> - 2003-03-05 15:46:52
|
On Wed, 2003-03-05 at 23:25, Antonino Daplas wrote: > > > > > > Yes, that's the Real Thing :-) fbcon_resize has a "fuzzy mode" too -- > > > it won't do an fb_set_var() if the change in dimensions is only a > > > fraction of a character's dimension. > > > > Ack. Is 16 fuzzy enough, what do you think? > > I think you should only accept modes where the difference is a fraction > of a character width or height. A difference more than that and > clear_margins() will not work correctly. > I apologize for my stupidity, fbdev does not know the font dimensions. I guess, we'll just need to really bring back fbset resizing. Tony |
|
From: James S. <jsi...@in...> - 2003-03-05 19:45:05
|
> > I think you should only accept modes where the difference is a fraction > > of a character width or height. A difference more than that and > > clear_margins() will not work correctly. > > > > I apologize for my stupidity, fbdev does not know the font dimensions. > I guess, we'll just need to really bring back fbset resizing. I disagree that fbset is the solution to all things. The problem is fbcon_resize is severally broken. The reality is that there are fixed mode resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we shoudl do is set the console mode fit slightly smaller than that the actually resolution. The reason being is partially drawn fonts at the bottom of the screen would look bad. So clearing the margins also has to be fixed. This way we clean up the screen for situtations where the console screen size doesn't quite fit the resolution. This is what shoudl be done. |
|
From: Thomas W. <th...@wi...> - 2003-03-05 22:20:34
|
James Simmons wrote: > I disagree that fbset is the solution to all things. The problem is > fbcon_resize is severally broken. The reality is that there are fixed mode > resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we > shoudl do is set the console mode fit slightly smaller than that the > actually resolution. The reason being is partially drawn fonts at the > bottom of the screen would look bad. So clearing the margins also has to > be fixed. This way we clean up the screen for situtations where the > console screen size doesn't quite fit the resolution. This is what shoudl > be done. Excuse me that I dare to comment on this as a total fbdev-rookie: Please think about usability, too. Forcing people to fiddle with rows and cols, requiring knowledge about font sizes and stuff is at least inappropriate. Folks are used to think in resolutions, that's what they understand, and that's what is most obvious. I can't imagine anyone caring about the amount of rows or columns on a text screen. BTW: What happens currently if I instruct console to replace the current font with a bigger one (if that's possible at run-time at all) ? Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: James S. <jsi...@in...> - 2003-03-06 00:19:56
|
> Excuse me that I dare to comment on this as a total fbdev-rookie: No problem. Its rare I take things personally. So I don't mind people critizing my work. You have to have a thick skin for this line of work. > Please think about usability, too. Forcing people to fiddle with rows > and cols, requiring knowledge about font sizes and stuff is at least > inappropriate. Folks are used to think in resolutions, that's what they > understand, and that's what is most obvious. I can't imagine anyone > caring about the amount of rows or columns on a text screen. Actually it is normal. Changing a console via stty has been around forever. When you ask what size is your VGA console you say 80x25. Now why is that. The main thing is people think of it as a text mode and second you really can't change it or boot to to many different size resolutions. Does this mean VGA console should be limited? NO!!! I plan to make vgacon some day changable in window size. So the final answer is: Portablity. You could use stty or some other program using the tty layer to change the resolution on any type of hardware running any type of console driver. The next best thing is some day we can get ride of con_switch in the upper console layers. We can just use set_font and vc_resize on VT switching since that is all you are doing on vc_switching. P.S If you look at struct winsize you have a ws_xpixel and a ws_ypixel field. The question is now do we place the exact size of the screen in pixels or vc->font.width[height]*width[height]. So it is stty program that is limiting and not the tty layer. In theory you could write fbset to use the proper tty ioctl to do this. > BTW: What happens currently if I instruct console to replace the current > font with a bigger one (if that's possible at run-time at all) ? It should work. |
|
From: Thomas W. <th...@wi...> - 2003-03-06 09:06:41
|
James Simmons wrote: > Actually it is normal. Changing a console via stty has been around > forever. When you ask what size is your VGA console you say 80x25. Now why > is that. The main thing is people think of it as a text mode and second > you really can't change it or boot to to many different size resolutions. > Does this mean VGA console should be limited? NO!!! I plan to make vgacon > some day changable in window size. So the final answer is: > > Portablity. > > You could use stty or some other program using the tty layer to change the > resolution on any type of hardware running any type of console driver. The > next best thing is some day we can get ride of con_switch in the upper > console layers. We can just use set_font and vc_resize on VT switching > since that is all you are doing on vc_switching. OK, if this is your final word on this, I - as the maintainer of a driver which due to LCD and TV handling only supports a (huge) number of built-in modes - am forced to do the following: If I receive a request for a mode that isn't supported, I go with the next larger one that is supported. Even if that leads to differences from requested 813x601 to displayed 1024x768. Hope you and your console code can deal with that then :) >>BTW: What happens currently if I instruct console to replace the current >>font with a bigger one (if that's possible at run-time at all) ? > > > It should work. ... and lead to a mode switch? Funny: If I switch from a 8x16 font to a bigger one, because I forgot my glasses, the mode is switched to a higher one, because the number of cols and rows hasn't changed, leaving me with a nearly identical charcter size? Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Antonino D. <ad...@po...> - 2003-03-06 01:17:06
|
On Thu, 2003-03-06 at 06:21, Thomas Winischhofer wrote: > James Simmons wrote: > > I disagree that fbset is the solution to all things. The problem is > > fbcon_resize is severally broken. The reality is that there are fixed mode > > resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we > > shoudl do is set the console mode fit slightly smaller than that the > > actually resolution. The reason being is partially drawn fonts at the > > bottom of the screen would look bad. So clearing the margins also has to > > be fixed. This way we clean up the screen for situtations where the > > console screen size doesn't quite fit the resolution. This is what shoudl > > be done. > > Excuse me that I dare to comment on this as a total fbdev-rookie: > > Please think about usability, too. Forcing people to fiddle with rows > and cols, requiring knowledge about font sizes and stuff is at least > inappropriate. Folks are used to think in resolutions, that's what they > understand, and that's what is most obvious. I can't imagine anyone > caring about the amount of rows or columns on a text screen. > If you are working in a console, then you indeed need to work on rows and columns. > BTW: What happens currently if I instruct console to replace the current > font with a bigger one (if that's possible at run-time at all) ? It will work, as the rows and columns are recalculated. Tony |
|
From: Antonino D. <ad...@po...> - 2003-03-06 01:17:00
|
On Thu, 2003-03-06 at 03:43, James Simmons wrote: > > > > I think you should only accept modes where the difference is a fraction > > > of a character width or height. A difference more than that and > > > clear_margins() will not work correctly. > > > > > > > I apologize for my stupidity, fbdev does not know the font dimensions. > > I guess, we'll just need to really bring back fbset resizing. > > I disagree that fbset is the solution to all things. The problem is > fbcon_resize is severally broken. The reality is that there are fixed mode fbcon_resize() is not that broken, it's only trying to do what it's supposed to do. It is indeed limited because it is trying to outguess the low-level drivers on the best resolution for a window size. However, the brokenness is really on the driver side. They are unable to change the video mode unless they are supplied with the correct timing parameters where in fact they actually have the best knowledge on how to calculate them. So the question: Do we let fbcon spoonfeed the timings to fbdev, or do we let the drivers calculate it for themselves? I go for the latter, as fbcon really should not have any business with hardware. > resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we > shoudl do is set the console mode fit slightly smaller than that the > actually resolution. The reason being is partially drawn fonts at the Yes, Geert's accel_clear_margin fix should help that. Tony |
Thanks for helping keep SourceForge clean.
X