Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James S. <jsi...@in...> - 2003-03-05 18:48:02
|
> This was one of the goals of the Ruby project, but I think it's mostly > the input layer that got into the kernel. Also the new fbdev api was apart of ruby. So all the low level changes went in. The upper console layer stuff didn't. This will be for the next developement kernel. > Fbcon needs to be cleaned up, a lot. It still implements the "current > console or foreground console" concept (only one console active at a > time). Also, this is more of a job for linuxconsole than fbdev. I may > be wrong though. Correct. This is more of a console thing. I do want to fix up fbcon now but only for bug fixes. |
|
From: Geert U. <ge...@li...> - 2003-03-05 18:47:52
|
On Wed, 5 Mar 2003, James Simmons wrote:
> > 0. Update all drivers
> >
> > Absolutely required
>
> Its getting there. Drivers not ported are:
>
> 68328fb.c
> S3triofb.c
> amifb.c
You can consider amifb done. I haven't sent it in yet, because I have a few
more cleanups to do.
> atafb.c
This one is tricky, since it needs new copyrect/fillrect/imageblit code for
Atari-style interleaved bitplanes. But since Atari is in a bad shape anyway
it's not that important.
> clgenfb.c
> cyber2000fb.c
> cyberfb.c
> imsttfb.c <- I have a nearly done driver. The old driver doesn't work
> on ix86. I tried it. Oh wells.
> leofb.c
Davem will probably take care of leofb.
> pm2fb.c
> pm3fb.c
> pvr2fb.c
> retz3fb.c
> sun3fb.c
Sun3fb will probably be replaced with the sbuslib stuff Davem wrote for SPARC.
> valkyriefb.c
> virgefb.c
The others cannot be that difficult to port. Most of them are unaccelerated
cfb-style cards.
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: James S. <jsi...@in...> - 2003-03-05 18:40:39
|
> > > 1. Text mode support? > > > > Would this work also on arches which don't traditionnaly do text mode ? > > Like ppc for example. > > Yes, pixel-based drawing is still the default. It's only for drivers > (matrox and sbus) where it might be needed. Only matrox has true text mode. Well also so did vga16fb but we have vgacon. > It does have one benefit though, the newer code should make it easier to > add an infrastructure on top of fbdev, such as xinerama-style support. > But this will be in the future. So little time. Also I did this so eventually when the DRI/fbdev merger happens it will make life easier for all of us. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:38:51
|
> So we just make fbcon permanently loaded unconditionally? The current > code allows 'rmmod fbcon', but it will freeze the system. Because no other console takes over. This is not a easy problem to solve. Which driver takes over when we switch from one console driver to another. > > Absolutely required > > Yes, which is why we need a feature freeze, so we can spend the rest of > the period on driver updating and bug fixing. I think we pretty much are there. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:37:21
|
> > 2. console resizing using fbset (besides stty)? > > What about dynamic multi-head support ? Next developement series. > > 8. feature freeze deadline? > > This would be for fbdev deature freeze, right, not for the drivers ? Correct. It pretty much is done. The only thing left to do IMO is cursor cleanup and docs and more buffer handling stuff. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:35:55
|
> > 1. Text mode support? > > Required by at least davem and petr Just Petr. I'm working to seperate the text code out into a matroxcon.c file. Needs alot more work tho. > > 2. console resizing using fbset (besides stty)? > > Nice, if it's not too much work. :-( I hope to improve fbcon to handle this. > 0. Update all drivers > > Absolutely required Its getting there. Drivers not ported are: 68328fb.c S3triofb.c amifb.c atafb.c clgenfb.c cyber2000fb.c cyberfb.c imsttfb.c <- I have a nearly done driver. The old driver doesn't work on ix86. I tried it. Oh wells. leofb.c pm2fb.c pm3fb.c pvr2fb.c retz3fb.c sun3fb.c valkyriefb.c virgefb.c Many of these drivers have been in state of code rotte for a long time :-( |
|
From: James S. <jsi...@in...> - 2003-03-05 18:30:49
|
> 1. Text mode support? We should remove it. Fbcon is to much bloat for text mode hardware. The only driver that does support a text mode matrox. Sparcs do not support text mode except for promcon. The issue was was a misunderstanding on teh flexiablity of imageblit. The name image blit stirs up this idea of the function has to be a place a image in buffer and send it on it way. This is not the case. Take a look at cg6.c. Fancy tricks are still possible. > 2. console resizing using fbset (besides stty)? Fbcon needs alot of work on this. In theory it shoudl be smart enought to handle the small details. > 3. support for unloading of fbcon if modular? It can be done. I used fbcon modular with MDA text mode. I can test the fbcon driver. The issue is if we have more than one vga card whcih vga to graphics card mapping. > 4. driver specified placement of buffers - for putcs method? Working on this. I think it is possible to merge the tileblit stuff with the new buffer code. > 5. flexible logo placement/overlayed logo? Not so important. More important is fixing fbcon to work with the logo code. You can't compile it right now. > 6. generic console display rotation? Not so important right now. I removed the poll stuff. using signals is better. > 7. Anything else? The cursor code needs cleanup and documentation. > 8. feature freeze deadline? We are very near this. IMO we have two things to work on. The buffer stuff and cleaning up the cursor code. |
|
From: James S. <jsi...@in...> - 2003-03-05 18:15:03
|
Hi folks.
I just pieced together various patches. I think we need to push this
code to linus. It has gotten pretty big.. Can people test it please
before I sen it.
Diff: http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
bk pull http://fbdev.bkbits.net/fbdev-2.5
This will update the following files:
drivers/video/aty128fb.c | 2353 -----
drivers/video/maxinefb.h | 37
drivers/video/pm2fb.h | 218
drivers/video/pm3fb.h | 1284 ---
drivers/video/pmag-ba-fb.h | 24
drivers/video/pmagb-b-fb.h | 32
drivers/video/sstfb.h | 355
include/asm-alpha/linux_logo.h | 27
include/asm-arm/linux_logo.h | 19
include/asm-i386/linux_logo.h | 27
include/asm-ia64/linux_logo.h | 28
include/asm-m68k/linux_logo.h | 924 --
include/asm-m68knommu/linux_logo.h | 13
include/asm-mips/linux_logo.h | 43
include/asm-mips/linux_logo_dec.h | 907 --
include/asm-mips/linux_logo_sgi.h | 919 --
include/asm-mips64/linux_logo.h | 919 --
include/asm-parisc/linux_logo.h | 1438 ---
include/asm-ppc64/linux_logo.h | 26
include/asm-sh/linux_logo.h | 1418 ---
include/asm-sparc/linux_logo.h | 934 --
include/asm-sparc64/linux_logo.h | 934 --
include/asm-um/linux_logo.h | 6
include/asm-x86_64/linux_logo.h | 29
include/linux/sisfb.h | 169
arch/mips64/Kconfig | 4
arch/ppc/syslib/prom.c | 3
arch/ppc/syslib/prom_init.c | 28
arch/ppc64/kernel/prom.c | 27
drivers/char/vt.c | 8
drivers/video/Kconfig | 23
drivers/video/Makefile | 7
drivers/video/aty/Makefile | 2
drivers/video/aty/aty128fb.c | 2362 +++++
drivers/video/aty/atyfb.h | 133
drivers/video/aty/atyfb_base.c | 2124 ++---
drivers/video/aty/mach64_accel.c | 51
drivers/video/aty/mach64_ct.c | 846 +
drivers/video/aty/mach64_cursor.c | 4
drivers/video/aty/mach64_gx.c | 18
drivers/video/aty/xlinit.c | 367
drivers/video/aty128fb.c | 162
drivers/video/cfbcopyarea.c | 218
drivers/video/cfbfillrect.c | 12
drivers/video/cfbimgblt.c | 255
drivers/video/cg6.c | 8
drivers/video/console/fbcon.c | 922 +-
drivers/video/console/fbcon.h | 4
drivers/video/console/newport_con.c | 69
drivers/video/console/vgacon.c | 801 -
drivers/video/dnfb.c | 9
drivers/video/fbmem.c | 340
drivers/video/fbmon.c | 3
drivers/video/ffb.c | 12
drivers/video/hgafb.c | 15
drivers/video/hitfb.c | 2
drivers/video/hpfb.c | 2
drivers/video/i810/i810.h | 9
drivers/video/i810/i810_accel.c | 150
drivers/video/i810/i810_main.c | 486 -
drivers/video/i810/i810_main.h | 14
drivers/video/logo/Kconfig | 75
drivers/video/logo/Makefile | 27
drivers/video/logo/clut_vga16.ppm | 20
drivers/video/logo/logo.c | 100
drivers/video/logo/logo_dec_clut224.ppm | 1604 +++
drivers/video/logo/logo_linux_clut224.ppm | 1604 +++
drivers/video/logo/logo_linux_mono.pbm | 203
drivers/video/logo/logo_linux_vga16.ppm | 1604 +++
drivers/video/logo/logo_mac_clut224.ppm | 1604 +++
drivers/video/logo/logo_parisc_clut224.ppm | 1604 +++
drivers/video/logo/logo_sgi_clut224.ppm | 1604 +++
drivers/video/logo/logo_sun_clut224.ppm | 1604 +++
drivers/video/logo/logo_superh_clut224.ppm | 1604 +++
drivers/video/logo/logo_superh_mono.pbm | 203
drivers/video/logo/logo_superh_vga16.ppm | 1604 +++
drivers/video/maxinefb.c | 2
drivers/video/modedb.c | 8
drivers/video/neofb.c | 113
drivers/video/pm2fb.c | 2
drivers/video/pm3fb.c | 3
drivers/video/pmag-ba-fb.c | 2
drivers/video/pmagb-b-fb.c | 2
drivers/video/q40fb.c | 1
drivers/video/radeonfb.c | 1
drivers/video/riva/fbdev.c | 405
drivers/video/riva/nv_driver.c | 156
drivers/video/riva/rivafb.h | 2
drivers/video/sgivwfb.c | 192
drivers/video/sis/300vtbl.h | 1373 ++-
drivers/video/sis/310vtbl.h | 2465 ++++-
drivers/video/sis/init.c | 5841 ++++++++-----
drivers/video/sis/init.h | 303
drivers/video/sis/init301.c |12286 ++++++++++++++++++-----------
drivers/video/sis/init301.h | 508 -
drivers/video/sis/initdef.h | 114
drivers/video/sis/oem300.h | 468 +
drivers/video/sis/oem310.h | 218
drivers/video/sis/osdef.h | 13
drivers/video/sis/sis.h | 10
drivers/video/sis/sis_accel.c | 166
drivers/video/sis/sis_accel.h | 509 +
drivers/video/sis/sis_main.c | 4526 ++++++----
drivers/video/sis/sis_main.h | 672 +
drivers/video/sis/vgatypes.h | 26
drivers/video/sis/vstruct.h | 683 +
drivers/video/skeletonfb.c | 6
drivers/video/softcursor.c | 72
drivers/video/sstfb.c | 16
drivers/video/tdfxfb.c | 31
drivers/video/tgafb.c | 18
drivers/video/tridentfb.c | 4
drivers/video/vga16fb.c | 145
include/linux/fb.h | 43
include/linux/linux_logo.h | 1435 ---
include/video/mach64.h | 75
include/video/maxinefb.h | 37
include/video/pm3fb.h | 1284 +++
include/video/pmag-ba-fb.h | 24
include/video/pmagb-b-fb.h | 32
include/video/sgivw.h | 40
include/video/sisfb.h | 191
include/video/sstfb.h | 355
include/video/vga.h | 23
scripts/Makefile | 4
scripts/pnmtologo |binary
scripts/pnmtologo.c | 523 +
127 files changed, 44400 insertions(+), 28675 deletions(-)
through these ChangeSets:
<jsi...@ma...> (03/03/05 1.939)
[FBDEV] Updates for the SIS fbdev driver to the new api. Removed poll. We wil use signals in the future instead.
<jsi...@ma...> (03/03/03 1.936)
[FBDEV] Accelerated functions pass in const structs.
[ATY128 FBDEV] Gcc compile issue fixes.
<jsi...@ma...> (03/03/03 1.935)
[GENRIC ACCEL] Megred David Millers changes with my own.
[FBCON] Small scrolling fix.
<jsi...@ma...> (03/02/28 1.931)
[FRAMEBUFFER]: cfbcopyarea accesses fb without using FB_{READ,WRITE}L.
<jsi...@ma...> (03/02/27 1.929)
[ATY FBDEV] Rage XL cards can now be booted with needed the BIOS :-)
[FBCON] Moving to use ring buffers and DMA cards.
<jsimmons@kozmo.(none)> (03/02/26 1.926)
[ATY128 FBDEV] Moved aty128fb to aty/ and a few minor changes so aty128fb.c compiles with the newest compiler standards.
<jsimmons@kozmo.(none)> (03/02/26 1.925)
[FBCON] More struct display cleanup. Also killed off static buffer for accel_putcs.
<jsi...@ma...> (03/02/24 1.923)
[FBDEV] Minor fixes for logo code.
[FBCON] More optimizations for drawing a string of characters.
[VGACON] Using more code from video/vga.h.
[VGA] Changes membase to unsigned long to support 64 bit platforms.
<jsi...@ma...> (03/02/19 1.913.1.3)
[FBDEEV] Need to add support to build pnmtologo.
<jsi...@ma...> (03/02/19 1.913.1.1)
Removed obsolete functions in fbcon.c and re-enabled mapping console(s) to a framebuffer device. A few compile fixes for rivafb and using standard macros for vgacon.c.
<jsi...@ma...> (03/02/16 1.913)
[FBDEV] Data in struct fb_image is now const.
[FBDEV] Updates to the logo code. We seperated it into two functions.
[I810 FBDEV] Updates to the driver. PCI hooks for PCI supsend and resume to save the AGP GART mapping during power saving.
[ATY 128] Add proper support for two graphics cards. Also added support for two more models of the Rage 128.
[SGIVW FBDEV] Updates for the SGI Visual Workstation framebuffer.
<jsi...@ma...> (03/02/13 1.910)
[LOGO] New better logo code.
[FBDEV] Moved a few more header files.
<jsi...@ma...> (03/02/11 1.909)
[FBCON] Removal of useless code.
<jsi...@ma...> (03/02/11 1.906)
[ATY FBDEV] Reversed mobilty patches. They busted every other card.
<jsi...@ma...> (03/02/09 1.900)
[ATY FBDEV] Updates to support Rage Mobility Chipstes.
<jsi...@ma...> (03/01/30 1.899)
[RIVA FBDEV] SUpprot Directcolor mode. Needed for some cards.
<jsimmons@kozmo.(none)> (03/01/28 1.897)
[NEOMAGIC FBDEV] Fix to work with no 21xx versions of the chip.
<jsi...@ma...> (03/01/28 1.889.53.3)
[RADEON FBDEV] Add cursor support. Now the cursor is back.
[RIVA FBDEV] Added support for interlace mode and are now using TRUECOLOR instead of DIRECTCOLOR. Setting the graphics card in DIRECTCOLOR confusses the X server.
<jsi...@ma...> (03/01/26 1.889.53.2)
Accel rountines pass in constant data into each function. The reason being was some of the code in the upper layers depended on the data being passed to the low level function not be altered because the upper layers was altering the data themselves.
Pan display fix for fbcon.c. p->vrow needed to be updated.
PPC build fix for fbmon.c
I810 fbdev updates.
<jsi...@ma...> (03/01/17 1.889.53.1)
[GENERIC ACCELERATION] Fixed the generic image drawing function tfor 64 bit machines.
[RIVA FBDEV] The cursor and imageblit functions have been fixed.
|
|
From: Geert U. <ge...@li...> - 2003-03-05 17:03:46
|
On 6 Mar 2003, Antonino Daplas wrote: > On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote: > > Antonino Daplas wrote: > > >> > 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. > > > > Just check this with the newest versions from fbdev at bk. In my code > > (which is, as I said in the beginning, the stock 2.5.63 kernel), > > fbcon_resize does NO check whatsoever. It stupidly calls set_var(). > > Of course. My tree is so modified that I forgot that Jame's latest > patch was not yet applied to the main tree :-) > > > > I think that might be one reason for what I see :) > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Note that this patch is dated Feb 20. In the mean time James applied at least your accel_putcs() optimizations and my logo updates. 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:43:17
|
On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote: > Antonino Daplas wrote: > >> > 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. > > Just check this with the newest versions from fbdev at bk. In my code > (which is, as I said in the beginning, the stock 2.5.63 kernel), > fbcon_resize does NO check whatsoever. It stupidly calls set_var(). Of course. My tree is so modified that I forgot that Jame's latest patch was not yet applied to the main tree :-) > > I think that might be one reason for what I see :) http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Note that there is still a bug in fbcon_resize(). 1. in fbcon_resize(), p->vrows must be updated unconditionally 2. fbcon_resize() in fbcon_switch() must be moved higher up the code, preferably before the scroll_phys_max calculation. Tony |
|
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: Thomas W. <th...@wi...> - 2003-03-05 16:20:50
|
Antonino Daplas wrote: >> > 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. Just check this with the newest versions from fbdev at bk. In my code (which is, as I said in the beginning, the stock 2.5.63 kernel), fbcon_resize does NO check whatsoever. It stupidly calls set_var(). I think that might be one reason for what I see :) Now for a plain dumb question: Is there a patch available to update my kernel tree to the latest fbdev stuff? (I don't intend to spend much time with bk) 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: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: 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: 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: 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: 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: 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: 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: Antonino D. <ad...@po...> - 2003-03-05 15:35:37
|
On Wed, 2003-03-05 at 22:40, Alex Bennee wrote: > > I think I understand now. When the fb_set_disp function is called I fill > in the display struction with the console display operations. I've got > two choices now: > > 1. Create a new fbcon_cfb16 file which notes the changed areas before > calling the generic function. > > 2. Patch the current fbcon_cfb16 (with a CONFIG option) to add the > change tracking facility in a more generic way. > > I guess the question is is it worth doing 2 as a potential upstream > patch? Or is this sort of thing so specialised I should just keep it all > packed in my own fb driver? > Either do #1 (create your own set -- check the popular drivers which has acceleration, they have their own set), or you can generically implement #2, I think. It may even become useful for devices without mappable graphics memory. Or as Geert suggested, just write a console driver if you don't need GUI. Tony |
|
From: Antonino D. <ad...@po...> - 2003-03-05 15:24:38
|
On Wed, 2003-03-05 at 22:16, Thomas Winischhofer wrote: > > Further to my mail from a few minutes ago: > > I wrote: > > 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. > > 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. > - This leads to the (unncessary) second mode switch during boot (when > the "initial console" starts), assumingly because the xres does not > match fontsize * rows, At boot time, there are several times the display changes (not necessarily mode changes) -- while the logo is being displayed, after the logo got displayed, and during init. > > - 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 > > Any hints? > 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()? Tony |
|
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: Antonino D. <ad...@po...> - 2003-03-05 15:24:34
|
On Wed, 2003-03-05 at 22:49, Sven Luther wrote: > On Wed, Mar 05, 2003 at 10:46:37PM +0800, Antonino Daplas wrote: > > > I thought that the new API, separating the fbcon layer from the fbdev > > > drivers would add support for this more easily. I guess it would be easy > > > for the Appian Jeronimo 2000 board, which has two permedia3 chips, and > > > thus can be seen as two separate devices. Cards with two ramdacs per > > > chip, like the G400, the later radeon's and most recent cards would need > > > driver level support, that is understandable, but is all there for fbcon > > > to take advantage of it ? What about multi-seat, with two full consoles, > > > with mouse and keyboard for each ? > > > > > > > This was one of the goals of the Ruby project, but I think it's mostly > > the input layer that got into the kernel. > > :((( > > > Fbcon needs to be cleaned up, a lot. It still implements the "current > > console or foreground console" concept (only one console active at a > > time). Also, this is more of a job for linuxconsole than fbdev. I may > > be wrong though. > > Mmm, do you know who is working on linuxconsole, and what their plan are ? James also. I think the site is http://linuxconsole.sourceforge.net. Tony |
|
From: Sven L. <lu...@dp...> - 2003-03-05 14:50:09
|
On Wed, Mar 05, 2003 at 10:46:37PM +0800, Antonino Daplas wrote: > > I thought that the new API, separating the fbcon layer from the fbdev > > drivers would add support for this more easily. I guess it would be easy > > for the Appian Jeronimo 2000 board, which has two permedia3 chips, and > > thus can be seen as two separate devices. Cards with two ramdacs per > > chip, like the G400, the later radeon's and most recent cards would need > > driver level support, that is understandable, but is all there for fbcon > > to take advantage of it ? What about multi-seat, with two full consoles, > > with mouse and keyboard for each ? > > > > This was one of the goals of the Ruby project, but I think it's mostly > the input layer that got into the kernel. :((( > Fbcon needs to be cleaned up, a lot. It still implements the "current > console or foreground console" concept (only one console active at a > time). Also, this is more of a job for linuxconsole than fbdev. I may > be wrong though. Mmm, do you know who is working on linuxconsole, and what their plan are ? > > > It does have one benefit though, the newer code should make it easier to > > > add an infrastructure on top of fbdev, such as xinerama-style support. > > > But this will be in the future. > > > > Mmm, I don't know if there is really a point to this, are there really > > all that much applications which do xinerama-like things on top of fbdev ? > > I rather thought that more higlevel userland apps would be doing this. > > like either xfree86 with chip-specific drivers or fbdev drivers, or > > directfb or something such. > > > > You're right, xinerama is mainly user-app. :))) Friendly, Sven Luther |
754 messages has been excluded from this view by a project administrator.
