Menu
▾
▴
linux-fbdev-devel
|
From: antirez <an...@in...> - 2001-05-14 11:05:35
|
On Mon, May 14, 2001 at 12:34:00PM +0000, Petr Vandrovec wrote: > > Yes, why to split in two drivers modes supported by the same > > hardware? > > I have vga16fb patched to support 256 colors for eons. I believe that > James maintains patch currently, but if not I can extract it from my tree. > It does 16color VGA planes, 16color packed pixels (on some hardware), > 256color VGA planes + packed pixels and native VGA textmode. Great! can I get this patch from some ftp? > > I did vga256fb as a stand-alone driver since: > > > > 1) It was a real-world work, the timeline was very short, and vga16 was > > not trivial to modify for a 256 color mode. > > 2) vga16fb is a FB_TYPE_VGAPLANES, but vga256fb is a > > FB_TYPE_PACKED_PIXELS driver. > > 3) vga256fb is "mode oriented", while vga16fb converts arbitrary > > xres, yres values to hardware settings. I'm not sure it's possible > > to do it for 256 colors tweaked modes. > > My driver does 320x200 in FB_TYPE_PACKED_PIXELS, or 360x480 with > FB_TYPE_VGA_PLANES&FB_AUX_VGA_PLANES_CFB8... I haven't a clue about how to implement this without something like a virtual framebuffer. So my idea was: until I have to map the framebuffer in the PC ram, it's better to emulate even the PACKED_PIXEL type to increase userspace software compatibility. > > user select an unchained mode the first time. While the linear emulation > > task is stopped once you return to a linear mode, the memory will > > never be freed (it may be in use by another console, also vmalloc()/vfree() > > 360*480 bytes every time a user enter/leave a unchained mode seems bad). > > Linear emulation cannot work for fbtv! Make sure that running fbtv on such > device will not overwrite innocent part of kernel ;-) I don't know how fbtv works, but it seems strange to me that my driver can't work with something in userspace. It just allocates some memory and uses it instead of the real VGA memory. Of course the driver provides a private mmap method when in linear emulation. Then a timer copy the "virtual framebuffer" in the real VGA memory N times in a second. It works with the fb console, GGI and other stuff without problems. I can only try to check fbtv to figure what kind of strange fbdev access it performs. thanks for the feedback, Salvatore -- Salvatore Sanfilippo <an...@in...> http://www.kyuzz.org/antirez finger an...@te... for PGP key 28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF |
|
From: Petr V. <VAN...@vc...> - 2001-05-14 13:47:11
|
On 14 May 01 at 13:04, antirez wrote: > > I have vga16fb patched to support 256 colors for eons. I believe that > > James maintains patch currently, but if not I can extract it from my tree. > > It does 16color VGA planes, 16color packed pixels (on some hardware), > > 256color VGA planes + packed pixels and native VGA textmode. > > Great! can I get this patch from some ftp? ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/ vga.gz => vga16fb patch; fbset -depth 8 -nonstd 0 => up to 320x200/256 colors, linear fbset -depth 8 -nonstd 1 => up to 360x480/256 colors, planes fbset -depth 4 -nonstd 0 => up to 720x480/16 colors, planes fbset -depth 4 -nonstd 1 => up to 720x182/16 (or 320x480/16), linear (due to some VGA incompatibilites last mode works either on ATI or on Matrox... you have to change code to switch behavior, ATI needs 'xoffset--' in vga16fb_pan_var, while Matrox does not, or vice versa...) fbset-through-tty.gz => patch to get 'fbset -fb /dev/tty* ...' to work (not tested with other fbdev than matroxfb) tabstop.gz => patch for fatal kernel memory corruption and TAB not working beyond column 160 > > My driver does 320x200 in FB_TYPE_PACKED_PIXELS, or 360x480 with > > FB_TYPE_VGA_PLANES&FB_AUX_VGA_PLANES_CFB8... > > I haven't a clue about how to implement this without something > like a virtual framebuffer. So my idea was: until I have to map > the framebuffer in the PC ram, it's better to emulate even the > PACKED_PIXEL type to increase userspace software compatibility. fbtv uses busmastering transfers when fbdev reports reasonable values. I have no idea what it checks, but on all my packed_pixels hardware it does busmastering, even on 320x200 VGA. > I don't know how fbtv works, but it seems strange to me that my > driver can't work with something in userspace. It just allocates > some memory and uses it instead of the real VGA memory. > Of course the driver provides a private mmap method when in > linear emulation. > Then a timer copy the "virtual framebuffer" in the real VGA memory > N times in a second. This buffer is not physically continuous and maybe that bttv driver does not expect videomemory to be nonlinear... > It works with the fb console, GGI and other stuff without problems. > I can only try to check fbtv to figure what kind of strange fbdev access > it performs. You'll see. If you have temporary buffer, it may work (if you do not check page dirty stuff). I though that you are doing some nopage stuff to remap videoram pages and change hardware state. On other side, fbtv has switch to do busmastering to main memory and then memcpy to videoram. But it is very slow. Petr Vandrovec van...@vc... |
|
From: antirez <an...@in...> - 2001-05-14 16:00:05
|
On Mon, May 14, 2001 at 03:45:51PM +0000, Petr Vandrovec wrote: > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/ > vga.gz => vga16fb patch; > fbset -depth 8 -nonstd 0 => up to 320x200/256 colors, linear > fbset -depth 8 -nonstd 1 => up to 360x480/256 colors, planes > fbset -depth 4 -nonstd 0 => up to 720x480/16 colors, planes > fbset -depth 4 -nonstd 1 => up to 720x182/16 (or 320x480/16), linear > (due to some VGA incompatibilites last mode works either on > ATI or on Matrox... you have to change code to switch behavior, > ATI needs 'xoffset--' in vga16fb_pan_var, while Matrox does not, > or vice versa...) > fbset-through-tty.gz => patch to get 'fbset -fb /dev/tty* ...' to work > (not tested with other fbdev than matroxfb) > tabstop.gz => patch for fatal kernel memory corruption and TAB not working > beyond column 160 I downloaded the patch, it seems your 256 color driver works in 360x480 only to provide a graphic console, but not with other userspace software that mmap() the video memory. Am I right? > > I haven't a clue about how to implement this without something > > like a virtual framebuffer. So my idea was: until I have to map > > the framebuffer in the PC ram, it's better to emulate even the > > PACKED_PIXEL type to increase userspace software compatibility. > > fbtv uses busmastering transfers when fbdev reports reasonable values. > I have no idea what it checks, but on all my packed_pixels hardware > it does busmastering, even on 320x200 VGA. I read the source code of fbtv, and it seems to perform a quite usual memory mapped I/O. Unfortunatelly I can't test it, I lacks a TV-card... > This buffer is not physically continuous and maybe that bttv driver > does not expect videomemory to be nonlinear... Again, It *seems* to mmap the fbdev, so every mmaped page contains a proper entry. I may assume that fbtv will work just as all the other applications. I tryed the 360x480 mode with GGI, SDL and so on, that also works doing memory mapped I/O (of course). > to remap videoram pages and change hardware state. On other side, fbtv > has switch to do busmastering to main memory and then memcpy to videoram. > But it is very slow. No I can't use the no-page trick to remap the videoram pages and change the hardware state, unfortunatelly: it seems not possible. I used it just to mmap the vmalloc()ed "virtual"-fb memory to userspace. There is a different kernel timer that updates the video memory and switches the registers to write to the proper video plane. BTW, I'm starting to think that my version isn't so advanced, it is the one shipped with xawtv-3.46. My version of fbtv does just memory mapped I/O that's supported by vga256fb. Maybe I'll buy a TV-card: now that Mr. Berlusconi is the italian's leader It's better to check what he is doing :( thanks for the patch, antirez -- Salvatore Sanfilippo <an...@in...> http://www.kyuzz.org/antirez finger an...@te... for PGP key 28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF |
|
From: James S. <jsi...@tr...> - 2001-05-14 16:50:30
|
> No I can't use the no-page trick to remap the videoram pages and change > the hardware state, unfortunatelly: it seems not possible. > I used it just to mmap the vmalloc()ed "virtual"-fb memory to userspace. There > is a different kernel timer that updates the video memory and > switches the registers to write to the proper video plane. Yuck! You can use the no-page trick to handle banked video cards. Its been done before. Noramlly VGA uses A000 to AFFFF. Once you go beyond that (B000) you can stop this is in a page fault handler and then program the register to switch to a new bank. Note you have to keep a eye on what the current bank is at all times (think SMP). You also have to flush the page tables so you can keep page faulting :-( |
|
From: antirez <an...@in...> - 2001-05-14 17:18:54
|
On Mon, May 14, 2001 at 09:50:15AM -0700, James Simmons wrote: > > > No I can't use the no-page trick to remap the videoram pages and change > > the hardware state, unfortunatelly: it seems not possible. > > I used it just to mmap the vmalloc()ed "virtual"-fb memory to userspace. There > > is a different kernel timer that updates the video memory and > > switches the registers to write to the proper video plane. > > Yuck! You can use the no-page trick to handle banked video cards. Its been > done before. Noramlly VGA uses A000 to AFFFF. Once you go beyond that > (B000) you can stop this is in a page fault handler and then program the > register to switch to a new bank. Note you have to keep a eye on what the > current bank is at all times (think SMP). You also have to flush the page > tables so you can keep page faulting :-( I tried something like this but I was unable to keep the page fault: where I can flush the page tables? memory.c will create a page entry with the physical address I returned by the no_page handler, so I should flush the page in mm/memory.c? The other problem is that without a PACKED_PIXEL display all the userspace currently available will not work. To make it working without too problems with old PCs was my goal. Also as you noted you need to flush the page table, and it seems it can't be done in a module ;( BTW the trick is very interesting! I'll try to implement it as 'nonstd == 2' or something like this if I understand how to keep the page faulting. thanks! Salvatore -- Salvatore Sanfilippo <an...@in...> http://www.kyuzz.org/antirez finger an...@te... for PGP key 28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF |
|
From: James S. <jsi...@tr...> - 2001-05-14 17:27:44
|
> > Yuck! You can use the no-page trick to handle banked video cards. Its been > > done before. Noramlly VGA uses A000 to AFFFF. Once you go beyond that > > (B000) you can stop this is in a page fault handler and then program the > > register to switch to a new bank. Note you have to keep a eye on what the > > current bank is at all times (think SMP). You also have to flush the page > > tables so you can keep page faulting :-( > > I tried something like this but I was unable to keep the page > fault: where I can flush the page tables? memory.c will create > a page entry with the physical address I returned by the no_page > handler, so I should flush the page in mm/memory.c? It can be done from a module or inside the kernel and it is platform independent. See linux/Documentation/cachetlb.txt. Note it is a expensive operation. I would only flush the TLB when you need to switch to another bank. > The other problem is that without a PACKED_PIXEL display all the > userspace currently available will not work. > To make it working without too problems with old PCs was my goal. Well if the video mmeory is not layed out in packed pixel mode their isn't much you can do. You have to let userland know that the mode is not packed pixels but something else. Then the userland program has to deal with it. |
|
From: James S. <jsi...@tr...> - 2001-05-15 03:13:23
|
> I tried something like this but I was unable to keep the page > fault: where I can flush the page tables? memory.c will create > a page entry with the physical address I returned by the no_page > handler, so I should flush the page in mm/memory.c? Defintely not in memory.c. It should be done in the driver. I can't remember of teh top of my head how it was done. I have to go look at some old code to handle this. > The other problem is that without a PACKED_PIXEL display all the > userspace currently available will not work. Their is not much you can do to get around this besides writing a native framebuffer :-). A emulation mode is way to slow. In theory you could this for atari and ilbm modes but it would go so sloooow. > Also as you noted you need to flush the page table, and it seems > it can't be done in a module ;( I seriously doubt it would be a problem. It might not be exported to modules but that is easily fixed. You also only want to flush the page tables only when you need to. Like when you leave one bank and go to another. |
|
From: Geert U. <ge...@li...> - 2001-05-15 06:14:10
|
On Mon, 14 May 2001, James Simmons wrote:
> > The other problem is that without a PACKED_PIXEL display all the
> > userspace currently available will not work.
>
> Their is not much you can do to get around this besides writing a native
> framebuffer :-). A emulation mode is way to slow. In theory you could this
> for atari and ilbm modes but it would go so sloooow.
I've been thinking about this. I see 2 possible approaches for emulation:
- Map the fake frame buffer read-only. Trap all write accesses and convert
between packed pixels and native format in the trap handler. Expensive due
to many context switches.
- Map the fake frame buffer read-only. In the trap handler, make the page
writable and rerun the write. In a timer handler, convert all pages that
are writable and make them read-only again. Faster, but more visible delay
(however, if the timer handler runs sufficiently frequent you won't
notice).
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: antirez <an...@in...> - 2001-05-15 09:16:15
|
On Tue, May 15, 2001 at 08:10:54AM +0200, Geert Uytterhoeven wrote: > On Mon, 14 May 2001, James Simmons wrote: > > > The other problem is that without a PACKED_PIXEL display all the > > > userspace currently available will not work. > > > > Their is not much you can do to get around this besides writing a native > > framebuffer :-). A emulation mode is way to slow. In theory you could this > > for atari and ilbm modes but it would go so sloooow. > > I've been thinking about this. I see 2 possible approaches for emulation: > > - Map the fake frame buffer read-only. Trap all write accesses and convert > between packed pixels and native format in the trap handler. Expensive due > to many context switches. > > - Map the fake frame buffer read-only. In the trap handler, make the page > writable and rerun the write. In a timer handler, convert all pages that > are writable and make them read-only again. Faster, but more visible delay > (however, if the timer handler runs sufficiently frequent you won't > notice). This is interesting IMHO. I tried to do something like this (i.e. to convert only the pages modified) using the dirty flag in the physical page, but experimenting problems: Instead to update all the video memory in the timer handler, vga256fb try to run all the pages checking for the dirty bit, if at least one page is dirty update the entire video memory. Then flush the TLB. As you can guess it's brain-dead since it can update just the page that changed, and it flushes all the entry from the TLB, but I stopped here because it works only for the graphic console, and not when I mmap the framebuffer from userspace. (you can see the code in the current vga256fb implementation but it's disabled by default by #ifdef, the feature is called SMARTUPDATE). I investigated a bit, and the problem seems that the dirty flag isn't unique: Both the no_page method or remap_page_range create a new page entry with a _different_ pte. Maybe with some hack I can create different pages entry with the pmd that points to the same pte, but this is broken anyway since not only the dirty flag will be unique, but also all the other flags :( But I guess that with the method you shown it can work, something like: - Map the fake frame buffer read-only. In the trap handler, make the page writable and set a bit in a bitmap. In the timer handler copy all the pages with the associated bit in the bitmap set to the real VGA memory (converting it from linear to planar of course), and remake the modified pages read-only. This is just what vga256fb do, but with the "update-only-the-modified-page" trick, that will save a lot of CPU all the times the only thing modified in the screen is the cursor, or the pointer, or nothing. The problem with this is that for a simple one-line scroll all the pages will be updated, and the trap called xres*yres/PAGE_SIZE times, so you optimized for all the times the console is idle, but it will be probably shower than the current vga256fb implementation for animations and so on. I'll try! cheers, Salvatore -- Salvatore Sanfilippo <an...@in...> http://www.kyuzz.org/antirez finger an...@te... for PGP key 28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF |
|
From: Petr V. <VAN...@vc...> - 2001-05-14 16:24:48
|
On 14 May 01 at 17:58, antirez wrote: > On Mon, May 14, 2001 at 03:45:51PM +0000, Petr Vandrovec wrote: > > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/ > > vga.gz => vga16fb patch; > > fbset -depth 8 -nonstd 0 => up to 320x200/256 colors, linear > > fbset -depth 8 -nonstd 1 => up to 360x480/256 colors, planes > > fbset -depth 4 -nonstd 0 => up to 720x480/16 colors, planes > > fbset -depth 4 -nonstd 1 => up to 720x182/16 (or 320x480/16), linear > > (due to some VGA incompatibilites last mode works either on > > ATI or on Matrox... you have to change code to switch behavior, > > ATI needs 'xoffset--' in vga16fb_pan_var, while Matrox does not, > > or vice versa...) > > fbset-through-tty.gz => patch to get 'fbset -fb /dev/tty* ...' to work > > (not tested with other fbdev than matroxfb) > > tabstop.gz => patch for fatal kernel memory corruption and TAB not working > > beyond column 160 > > I downloaded the patch, it seems your 256 color driver works > in 360x480 only to provide a graphic console, but not with > other userspace software that mmap() the video memory. > Am I right? It provides mmap. But application must understand FB_AUX_PLANES_CFB8 videomode, not packed pixels. > > fbtv uses busmastering transfers when fbdev reports reasonable values. > > I have no idea what it checks, but on all my packed_pixels hardware > > it does busmastering, even on 320x200 VGA. > > I read the source code of fbtv, and it seems to perform a quite > usual memory mapped I/O. Unfortunatelly I can't test it, I > lacks a TV-card... It then passes this address down to bttv, which converts virtual address back to physical and pushes data directly there. > No I can't use the no-page trick to remap the videoram pages and change > the hardware state, unfortunatelly: it seems not possible. > I used it just to mmap the vmalloc()ed "virtual"-fb memory to userspace. There > is a different kernel timer that updates the video memory and > switches the registers to write to the proper video plane. If there is some memory somewhere it will work, as bttv supports non-continuous data stores due to its ability to write directly to userspace. Petr Vandrovec van...@vc... |
|
From: antirez <an...@in...> - 2001-05-14 16:33:07
|
On Mon, May 14, 2001 at 06:23:20PM +0000, Petr Vandrovec wrote: > > I downloaded the patch, it seems your 256 color driver works > > in 360x480 only to provide a graphic console, but not with > > other userspace software that mmap() the video memory. > > Am I right? > > It provides mmap. But application must understand FB_AUX_PLANES_CFB8 > videomode, not packed pixels. Ok > > I read the source code of fbtv, and it seems to perform a quite > > usual memory mapped I/O. Unfortunatelly I can't test it, I > > lacks a TV-card... > > It then passes this address down to bttv, which converts virtual address > back to physical and pushes data directly there. Now it's clear! I didn't understood that the one to write directly to the video memory was the bttv driver. > If there is some memory somewhere it will work, as bttv supports > non-continuous data stores due to its ability to write directly to userspace. > Petr Vandrovec > van...@vc... Perfect. Thanks for the clarification! -- Salvatore Sanfilippo <an...@in...> http://www.kyuzz.org/antirez finger an...@te... for PGP key 28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF |
|
From: Petr V. <VAN...@vc...> - 2001-05-14 10:35:46
|
On 14 May 01 at 11:31, antirez wrote: > On Mon, May 14, 2001 at 08:33:00AM +0200, Geert Uytterhoeven wrote: > > On Sat, 12 May 2001, antirez wrote: > > > you can download the quite useless vga256fb device driver > > > at http://www.kyuzz.org/antirez/vga256fb.html. > > > > > > I used it for an embedded project, than I added the "tweaked" > > > VGA modes for fun, with a software hack. > > > While useless, to run at 360x480 in 256 colors with a standard > > > VGA card can be funny ;) > > > > > > As you can guess, this driver will waste your CPU and RAM > > > when in linear emulation mode. > > > > Would it be useful to integrate vga16fb and vga256fb? > > Yes, why to split in two drivers modes supported by the same > hardware? I have vga16fb patched to support 256 colors for eons. I believe that James maintains patch currently, but if not I can extract it from my tree. It does 16color VGA planes, 16color packed pixels (on some hardware), 256color VGA planes + packed pixels and native VGA textmode. > I did vga256fb as a stand-alone driver since: > > 1) It was a real-world work, the timeline was very short, and vga16 was > not trivial to modify for a 256 color mode. > 2) vga16fb is a FB_TYPE_VGAPLANES, but vga256fb is a > FB_TYPE_PACKED_PIXELS driver. > 3) vga256fb is "mode oriented", while vga16fb converts arbitrary > xres, yres values to hardware settings. I'm not sure it's possible > to do it for 256 colors tweaked modes. My driver does 320x200 in FB_TYPE_PACKED_PIXELS, or 360x480 with FB_TYPE_VGA_PLANES&FB_AUX_VGA_PLANES_CFB8... > user select an unchained mode the first time. While the linear emulation > task is stopped once you return to a linear mode, the memory will > never be freed (it may be in use by another console, also vmalloc()/vfree() > 360*480 bytes every time a user enter/leave a unchained mode seems bad). Linear emulation cannot work for fbtv! Make sure that running fbtv on such device will not overwrite innocent part of kernel ;-) Best regards, Petr Vandrovec van...@vc... |
|
From: Geert U. <ge...@li...> - 2001-05-14 11:11:45
|
On Mon, 14 May 2001, Petr Vandrovec wrote:
> On 14 May 01 at 11:31, antirez wrote:
> > user select an unchained mode the first time. While the linear emulation
> > task is stopped once you return to a linear mode, the memory will
> > never be freed (it may be in use by another console, also vmalloc()/vfree()
> > 360*480 bytes every time a user enter/leave a unchained mode seems bad).
>
> Linear emulation cannot work for fbtv! Make sure that running fbtv on such
> device will not overwrite innocent part of kernel ;-)
Does user space mmap() works on a vmalloc()'ed frame buffer?
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: antirez <an...@in...> - 2001-05-14 11:20:13
|
On Mon, May 14, 2001 at 01:08:32PM +0200, Geert Uytterhoeven wrote: > On Mon, 14 May 2001, Petr Vandrovec wrote: > > On 14 May 01 at 11:31, antirez wrote: > > > user select an unchained mode the first time. While the linear emulation > > > task is stopped once you return to a linear mode, the memory will > > > never be freed (it may be in use by another console, also vmalloc()/vfree() > > > 360*480 bytes every time a user enter/leave a unchained mode seems bad). > > > > Linear emulation cannot work for fbtv! Make sure that running fbtv on such > > device will not overwrite innocent part of kernel ;-) > > Does user space mmap() works on a vmalloc()'ed frame buffer? Yep, see my implementation. You can just put the code in the linux's virtual framebuffer implementation, that's broken. I did it in two ways: with the nopage method of vma (I vote for this) and remap(ing)_page_range() every physical page of the vmalloc()ed memory. My driver is using the nopage method, that's IMHO the better way to do it. For this reasons I guess my driver will work with all the userspace applications around. *not only* as graphic console. antirez -- Salvatore Sanfilippo <an...@in...> http://www.kyuzz.org/antirez finger an...@te... for PGP key 28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF |
|
From: James S. <jsi...@tr...> - 2001-05-14 16:44:12
|
> Does user space mmap() works on a vmalloc()'ed frame buffer? It can but you need to provide a special mmap function for it. |
|
From: James S. <jsi...@tr...> - 2001-05-14 16:42:19
|
> > I have vga16fb patched to support 256 colors for eons. I believe that > > James maintains patch currently, but if not I can extract it from my tree. I maintain it for the ruby tree. I rewrote the driver to use the new api. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X