Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2001-06-15 21:53:53
|
On 15 Jun 01 at 23:05, Martin Erhardsen wrote:
> I have noticed two bugs in most fbcon implementations of putcs.
>
> They only use the colours of the first colour/character pair.
>
> They don't wrap correctly (like vga) at the end of the line.
>
> I am wondering why no one has noticed this before.
Because of this is correct behavior. Upper layer passes data to
putcs() so that end of line is not crossed and all characters have
same color.
If some console code passes buffer with different attributes or buffer
which crosses end of line, then that console code is buggy.
Best regards,
Petr Vandrovec
van...@vc...
P.S.: James, if this is not in fbdev API doc, it definitely should.
|
|
From: James S. <jsi...@tr...> - 2001-06-15 22:58:26
|
> Because of this is correct behavior. Upper layer passes data to > putcs() so that end of line is not crossed and all characters have > same color. > > If some console code passes buffer with different attributes or buffer > which crosses end of line, then that console code is buggy. > Best regards, > Petr Vandrovec > van...@vc... > > P.S.: James, if this is not in fbdev API doc, it definitely should. Yep. putcs write only one line and does not wrap. This is a good thing as it makes life easier. putcs is used when you do a cat /dev/tty3 for example. It prints the current contents of the screen but note no colors/attributes. You use vcsa to do this instead. |
|
From: Martin E. <Mar...@ma...> - 2001-06-15 23:07:04
|
> Yep. putcs write only one line and does not wrap. This is a good thing > as it makes life easier. putcs is used when you do a cat /dev/tty3 for > example. It prints the current contents of the screen but note no > colors/attributes. You use vcsa to do this instead. Okay that case does not occur. I have a couple of further API questions. How about reading 3 bytes past the end of the bitmap. I have noticed that 3dfx driver carefully avoids this, but if this were allowed, it would avoid having a special case for the last 3 bytes. Why not make the fbcon colormap 32 bits in 16 bpp modes too. This would use some extra bytes, but would avoid deciding between reading 16 or 32 bits from the colormap in putc and putcs. |
|
From: Geert U. <ge...@li...> - 2001-06-16 08:51:11
|
On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> I have a couple of further API questions.
>
> How about reading 3 bytes past the end of the bitmap.
> I have noticed that 3dfx driver carefully avoids this,
> but if this were allowed, it would avoid having a special case for
> the last 3 bytes.
Which bitmap?
> Why not make the fbcon colormap 32 bits in 16 bpp modes too.
> This would use some extra bytes, but would avoid deciding
> between reading 16 or 32 bits from the colormap in putc and putcs.
Because it's not a real colormap but a map from console colors to pixel values?
(In theory we we would need it for bpp 8 etc. too). What with a card that has
pixels larger than 32 bit?
In 2.5.x you'll be able to do what you want, since the contents can be device
private, through your card's accel implementation.
Well, in fact you can use 32 bpp in your driver in 2.4.x as well, as long as
you no longer use _any_ fbcon-cfb* routines.
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: Martin E. <Mar...@ma...> - 2001-06-16 10:21:43
|
----- Original Message ----- From: "Geert Uytterhoeven" <ge...@li...> To: "Martin Erhardsen" <Mar...@ma...> Cc: "James Simmons" <jsi...@tr...>; <lin...@li...> Sent: Saturday, June 16, 2001 10:48 AM Subject: Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs > On Sat, 16 Jun 2001, Martin Erhardsen wrote: > > I have a couple of further API questions. > > > > How about reading 3 bytes past the end of the bitmap. > > I have noticed that 3dfx driver carefully avoids this, > > but if this were allowed, it would avoid having a special case for > > the last 3 bytes. > > Which bitmap? The bitmap used for drawing characters with putc and putcs. I was wondering if reading 3 extra bytes past the end could cause a segmantation fault. |
|
From: Geert U. <ge...@li...> - 2001-06-16 14:21:37
|
On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> From: "Geert Uytterhoeven" <ge...@li...>
> > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > I have a couple of further API questions.
> > >
> > > How about reading 3 bytes past the end of the bitmap.
> > > I have noticed that 3dfx driver carefully avoids this,
> > > but if this were allowed, it would avoid having a special case for
> > > the last 3 bytes.
> >
> > Which bitmap?
>
> The bitmap used for drawing characters with putc and putcs.
You mean the font data?
> I was wondering if reading 3 extra bytes past the end could
> cause a segmantation fault.
In theory yes. But why would you want to read more fontdata than is present?
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: Martin E. <Mar...@ma...> - 2001-06-16 16:58:24
|
----- Original Message ----- From: "Geert Uytterhoeven" <ge...@li...> To: "Martin Erhardsen" <Mar...@ma...> Cc: "James Simmons" <jsi...@tr...>; <lin...@li...> Sent: Saturday, June 16, 2001 4:18 PM Subject: Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs > On Sat, 16 Jun 2001, Martin Erhardsen wrote: > > From: "Geert Uytterhoeven" <ge...@li...> > > > On Sat, 16 Jun 2001, Martin Erhardsen wrote: > > > > I have a couple of further API questions. > > > > > > > > How about reading 3 bytes past the end of the bitmap. > > > > I have noticed that 3dfx driver carefully avoids this, > > > > but if this were allowed, it would avoid having a special case for > > > > the last 3 bytes. > > > > > > Which bitmap? > > > > The bitmap used for drawing characters with putc and putcs. > > You mean the font data? Yes > > I was wondering if reading 3 extra bytes past the end could > > cause a segmantation fault. > > In theory yes. But why would you want to read more fontdata than is present? The 3dfx driver uses unalligned 32 bit loads to read the font data, and has a special case for the last bytes to avoid reading past the character data. If reading a few extra bytes were allowed, then this could be avoided by just reading the extra data, because the accel engine doesn't use the extra bytes in the last u32. Are unalligned loads a bad thing in kernel drivers? I could modify the driver, so that it only loads u32s from alligned adresses, but this would either make character sizes where the number of bytes in a character is 3 modulo 4 (i.e. 7,11,15,..) slight slower, because it would require writing a extra u32 to the accel engine in half of the possible allignments, or this this extra write could be avoided by shifting the data before writing it to the accel engine. |
|
From: Geert U. <ge...@li...> - 2001-06-16 21:24:26
|
On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> ----- Original Message -----
> From: "Geert Uytterhoeven" <ge...@li...>
> > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > From: "Geert Uytterhoeven" <ge...@li...>
> > > > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > > > I have a couple of further API questions.
> > > > >
> > > > > How about reading 3 bytes past the end of the bitmap.
> > > > > I have noticed that 3dfx driver carefully avoids this,
> > > > > but if this were allowed, it would avoid having a special case for
> > > > > the last 3 bytes.
> > > >
> > > > Which bitmap?
> > >
> > > The bitmap used for drawing characters with putc and putcs.
> >
> > You mean the font data?
>
> Yes
>
> > > I was wondering if reading 3 extra bytes past the end could
> > > cause a segmantation fault.
> >
> > In theory yes. But why would you want to read more fontdata than is present?
>
> The 3dfx driver uses unalligned 32 bit loads to read the font data, and
Ugh, unaligned 32 bit loads...
> has a special case for the last bytes to avoid reading past the character data.
> If reading a few extra bytes were allowed, then this could be avoided by
> just reading the extra data, because the accel engine doesn't use the extra
> bytes in the last u32.
>
> Are unalligned loads a bad thing in kernel drivers? I could modify the
> driver, so that it only loads u32s from alligned adresses, but this would
> either make character sizes where the number of bytes in a character
> is 3 modulo 4 (i.e. 7,11,15,..) slight slower, because it would require
> writing a extra u32 to the accel engine in half of the possible allignments,
> or this this extra write could be avoided by shifting the data before writing
> it to the accel engine.
The main problem is that not all architectures support unaligned accesses. If
you want to use them, you must use the get_unaligned() functions. Currently
tdxfb doesn't do that.
Speedwise is not that bad these days anymore (supposed your CPU supports it),
since font data is in cached memory and the memory controller will load the
whole cacheline anyway, and the CPU runs at a much higher speed than the memory
bus. Even doing successive individual byte loads won't slow it down much if
your CPU is sufficiently faster than your memory bus.
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: Martin E. <Mar...@ma...> - 2001-06-17 11:05:52
|
> > > > Are unalligned loads a bad thing in kernel drivers? I could modify the > > driver, so that it only loads u32s from alligned adresses, but this would > > either make character sizes where the number of bytes in a character > > is 3 modulo 4 (i.e. 7,11,15,..) slight slower, because it would require > > writing a extra u32 to the accel engine in half of the possible allignments, > > or this this extra write could be avoided by shifting the data before writing > > it to the accel engine. > > The main problem is that not all architectures support unaligned accesses. If > you want to use them, you must use the get_unaligned() functions. Currently > tdxfb doesn't do that. That is a nice way of abstracting away the difference. There is however a small problem with this approach and uncached memory. When reading n consecutive words, it would read 2n words instead of the n+1 words required when one manually alligns the data. This means that this is not the best way of reading consecutive words from the framebuffer. > Speedwise is not that bad these days anymore (supposed your CPU supports it), > since font data is in cached memory and the memory controller will load the > whole cacheline anyway, and the CPU runs at a much higher speed than the memory > bus. Even doing successive individual byte loads won't slow it down much if > your CPU is sufficiently faster than your memory bus. I guess that I am just old-fashioned, and would prefer my inner loops as simple as possible, even if this might be up to 5% slower sometimes, so I won't use those allignment functions in this case. To increase the speed, I probably shouldn't be using PIO, but instead set up a command FIFO, so that the commands can be sent asyncroneously to the accel engine. This way it is possible to write many commands into a buffer, without having to wait for the accel engine. |
×
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