Menu
▾
▴
linux-fbdev-devel
|
From: Romain D. <do...@ir...> - 2001-06-13 13:32:53
|
Hello, Is there a way to distinguish 15 and 16 bpp in 16bits pixels in the fbdev/fbcon layer ? pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16 and support both internally, is there a requirement that CFB16 is one or the other, ... ? TIA -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Geert U. <ge...@li...> - 2001-06-13 13:52:39
|
On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> the fbdev/fbcon layer ?
Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> and support both internally, is there a requirement that
> CFB16 is one or the other, ... ?
Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
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: Romain D. <do...@ir...> - 2001-06-13 14:25:46
|
Geert Uytterhoeven wrote:
> Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
>
> Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
How does the user tell the system what he wants, then ? Will fbset
recognize both -depth 15 and -depth 16 and fill the fields properly ?
Right now, pm3fb just disregard whatever is in the length fields
and use RGB8888/RGB565/CI8 for 32/16/8bpp (shame on me). Is there any
requirements on the userland/the kernel about what is acceptable ?
One could require RGB10_10_10_2 or RG232 or RGB4444, what is
the driver supposed to to in case it doesn't support the required
mode : change to a similar mode, do nothing,... ?
TIA
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre
do...@ir... | -- Boris Vian
|
|
From: Geert U. <ge...@li...> - 2001-06-13 15:30:18
|
On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> >
> > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
>
> How does the user tell the system what he wants, then ? Will fbset
> recognize both -depth 15 and -depth 16 and fill the fields properly ?
No, use the -rgba option to specify the bitfield lengths.
> Right now, pm3fb just disregard whatever is in the length fields
> and use RGB8888/RGB565/CI8 for 32/16/8bpp (shame on me). Is there any
> requirements on the userland/the kernel about what is acceptable ?
> One could require RGB10_10_10_2 or RG232 or RGB4444, what is
> the driver supposed to to in case it doesn't support the required
> mode : change to a similar mode, do nothing,... ?
Driver should round up values until they fit, or return an error.
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: Sven L. <lu...@dp...> - 2001-06-13 14:27:07
|
On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > the fbdev/fbcon layer ?
>
> Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
>
> > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > and support both internally, is there a requirement that
> > CFB16 is one or the other, ... ?
>
> Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
So i suppose saying fbset -depth 15 could be done to switch the fb to
RGBA5551 mode ?
BTW, what is fbset -depth 24 supposed to do, especially if the chip only
support 8, 16, and 32 bpp ?
should only fbset -depth 32 be supported ?
Also, i am experiencing some (maybe hardware) bugs, and would like to reset
the graphic chip. Is there an existing way to do this kind of stuff via ioctl
ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
would be really happy with it).
Friendly,
Sven Luther
|
|
From: Geert U. <ge...@li...> - 2001-06-13 15:32:31
|
On Wed, 13 Jun 2001, Sven LUTHER wrote:
> On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > > the fbdev/fbcon layer ?
> >
> > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> >
> > > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > > and support both internally, is there a requirement that
> > > CFB16 is one or the other, ... ?
> >
> > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
>
> So i suppose saying fbset -depth 15 could be done to switch the fb to
> RGBA5551 mode ?
No, -depth actually means bits-per-pixel in fbset (yes this is a bug).
> BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> support 8, 16, and 32 bpp ?
Fbset should do nothing special, the fbdev should round up
fb_var_screeninfo.bpp to 32.
> should only fbset -depth 32 be supported ?
Huh?
> Also, i am experiencing some (maybe hardware) bugs, and would like to reset
> the graphic chip. Is there an existing way to do this kind of stuff via ioctl
> ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
> would be really happy with it).
You can add a fbdev specific ioctl until you fixed the bug/worked around it.
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: Sven L. <lu...@dp...> - 2001-06-13 16:09:15
|
On Wed, Jun 13, 2001 at 05:29:44PM +0200, Geert Uytterhoeven wrote:
> On Wed, 13 Jun 2001, Sven LUTHER wrote:
> > On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > > > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > > > the fbdev/fbcon layer ?
> > >
> > > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> > >
> > > > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > > > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > > > and support both internally, is there a requirement that
> > > > CFB16 is one or the other, ... ?
> > >
> > > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
> >
> > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > RGBA5551 mode ?
>
> No, -depth actually means bits-per-pixel in fbset (yes this is a bug).
Ok, what about the fbdev driver silently converting bpp 15 to bpp 16 and
setting RGB5551 ?
Friendly,
Sven Luther
|
|
From: Geert U. <ge...@li...> - 2001-06-13 16:23:44
|
On Wed, 13 Jun 2001, Sven LUTHER wrote:
> On Wed, Jun 13, 2001 at 05:29:44PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 13 Jun 2001, Sven LUTHER wrote:
> > > On Wed, Jun 13, 2001 at 03:49:41PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, 13 Jun 2001, Romain Dolbeau wrote:
> > > > > Is there a way to distinguish 15 and 16 bpp in 16bits pixels in
> > > > > the fbdev/fbcon layer ?
> > > >
> > > > Yes, by looking at the fb_var_screeninfo.{red,green,blue}.length fields.
> > > >
> > > > > pm3fb support RGB565 in 16bpp, and I was just asked for 15bpp
> > > > > (RGB555 + 1 bit Alpha or whatever). Do I simply reuse CFB16
> > > > > and support both internally, is there a requirement that
> > > > > CFB16 is one or the other, ... ?
> > > >
> > > > Cfb16 is the memory organization: packed 16 bits per pixel. How a pixel looks
> > > > like internally doesn't matter. So both RGB555 and RGB565 use fbcon-cfb16.c.
> > >
> > > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > > RGBA5551 mode ?
> >
> > No, -depth actually means bits-per-pixel in fbset (yes this is a bug).
>
> Ok, what about the fbdev driver silently converting bpp 15 to bpp 16 and
> setting RGB5551 ?
Yes, that's allowed.
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: Romain D. <do...@ir...> - 2001-06-14 16:12:29
|
Geert Uytterhoeven wrote: > No, -depth actually means bits-per-pixel in fbset (yes this is a bug). Are those details documented anywhere ? That would make life easier for you not to have to answer questions on fbset all the time :-) I'm about to add the following blurb to the pm3fb home page to explain details, so 1) did I understand fbset correctly 2) is it understandable ? (the pm3fb part is a little optimistic as the code isn't finished yet ;-) TIA #### Depth, BitsPerPixel and fbset There's a little bit of confusion on the proper use of some terms in this page and in the fbset software. + Depth should be the actual number of bits used for the color of the pixel (above, significants bits) + BitsPerPixel should be the actual number of bits used in the memory of the framebuffer per pixel, regardless of depth. Unfortunately, fbset -depth X should really be fbset -bpp X as it means 'set the framebuffer to that number of bits per pixels in memory, or more'. For TrueColor mode, there's an option -rgba R,G,B,A to give the number of significant bits for each color component. So to get Depth 15 in 16 BitsPerPixels, i.e 5 bits for each of red, green and blue plus a spare bit, one should use: fbset -depth 16 -rgba 5,5,5,1. At the moment, if you use fbset -depth 15, pm3fb will also use RGB 5551 and 16bpp but I'm not sure it's the right behavior. fbset -depth 16 will default to RGB 565. ##### -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: James S. <jsi...@tr...> - 2001-06-13 15:47:45
|
> So i suppose saying fbset -depth 15 could be done to switch the fb to
> RGBA5551 mode ?
>
> BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> support 8, 16, and 32 bpp ?
fb_set_var should be done in two parts. The first part checks the purposed
var and sees if the hardware can support it. The second part should set
the resolution if the mode is supported. This is what I have done for the
new api. Basically we have something like this:
int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
int oldbpp, err;
if (memcmp(&info->var, var, sizeof(var))) {
if ((err = info->fbops->fb_check_var(var, info)))
return err;
if ((var->activate & FB_ACTIVATE_MASK) == FB_ACTIVATE_NOW) {
oldbpp = info->var.bits_per_pixel;
info->var = *var;
if (info->fbops->fb_set_par)
info->fbops->fb_set_par(info);
if (info->cursor.enable) {
info->cursor.set = FB_CUR_SETALL;
info->fbops->fb_cursor(info, &info->cursor);
}
if (oldbpp != var->bits_per_pixel) {
if ((err = fb_alloc_cmap(&info->cmap, 0, 0)))
return err;
fb_set_cmap(&info->cmap, 1, info);
}
}
var->activate = 0;
}
return 0;
}
> should only fbset -depth 32 be supported ?
If that is all the card can support then yes. Say you pass a var that is
correct in everyway except for the depth then you could have the check_var
funciton alter the var and pass it back to userland (by changing var.activate).
This way if userland does a FB_ACTIVATE_TEST check_var only gets called
when testing the mode. Yes it is for 2.5.X but current drivers could
follow a similar layout now. It will also save much work in porting stuff
over when 2.5.X comes out.
> Also, i am experiencing some (maybe hardware) bugs, and would like to reset
> the graphic chip. Is there an existing way to do this kind of stuff via ioctl
> ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev
> would be really happy with it).
Not really. You could make it reset the card when unloading the module.
Log in remotely or use a serial console to do this.
In theory when you run the program reset. It should reset your console
back to the default mode. Unfortunely the console system doesn't work that
way :-(
|
|
From: Sven L. <lu...@dp...> - 2001-06-13 15:59:51
|
On Wed, Jun 13, 2001 at 08:47:21AM -0700, James Simmons wrote: > > > So i suppose saying fbset -depth 15 could be done to switch the fb to > > RGBA5551 mode ? > > > > BTW, what is fbset -depth 24 supposed to do, especially if the chip only > > support 8, 16, and 32 bpp ? > > should only fbset -depth 32 be supported ? mmm, well, the problem is that most current 'millions of color' modes are in truth depth 24 ones, which are internally either 32bpp (as in the permedia3 case) or 24bpp (saves bandwith, but no alpha channel and you may be forced to do some shifting). Now, if a user wants to set a depth of 24, what does he mean ? mostly it is RGB 888, but for the user the presence of an alpha channel (32bpp) or not (24bpp) may not be that important. Especially Since X is using per default depth 24 with bpp 32. So what should happen if you try to set depth 24 with fbset ? Silently set 32 bpp ? reject it ? Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or rejected ? > > Also, i am experiencing some (maybe hardware) bugs, and would like to reset > > the graphic chip. Is there an existing way to do this kind of stuff via ioctl > > ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev > > would be really happy with it). > > Not really. You could make it reset the card when unloading the module. or when loading it ? > Log in remotely or use a serial console to do this. BTW, if dual head was really working i could do that, wait no, they both would be using pm3fb. Would it be possible to run the vga text console on one head, and a pm3fb on the other ? (same chip). > In theory when you run the program reset. It should reset your console > back to the default mode. Unfortunely the console system doesn't work that > way :-( Well, the real problem here is not so much to reset to default mode, but to do a hardware reset on the chip, and initialize it again, to see if the problem goes away. The porblem only appears from time to time (but stays if i only do a reboot :(((), and it seems that either the memory has some problem, or more probably the accel unit, as this happens only when accel is enabled, and there are areas where various pixels get some of their bits sets to 1. Friendly, Sven Luther > |
|
From: Geert U. <ge...@li...> - 2001-06-13 16:08:56
|
On Wed, 13 Jun 2001, Sven LUTHER wrote:
> On Wed, Jun 13, 2001 at 08:47:21AM -0700, James Simmons wrote:
> > > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > > RGBA5551 mode ?
> > >
> > > BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> > > support 8, 16, and 32 bpp ?
>
> > > should only fbset -depth 32 be supported ?
>
> mmm, well, the problem is that most current 'millions of color' modes are in
> truth depth 24 ones, which are internally either 32bpp (as in the permedia3
> case) or 24bpp (saves bandwith, but no alpha channel and you may be forced to
> do some shifting).
>
> Now, if a user wants to set a depth of 24, what does he mean ? mostly it is
> RGB 888, but for the user the presence of an alpha channel (32bpp) or not
> (24bpp) may not be that important. Especially Since X is using per default
> depth 24 with bpp 32.
>
> So what should happen if you try to set depth 24 with fbset ? Silently set 32
> bpp ? reject it ?
Round it up to 32.
> Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or
> rejected ?
You cannot specify `depth 15', only `bits per pixel 15', which will be rounded
up to the driver to 16 (in most cases).
Set {red,green,blue,transp}.length to indicate which 16 bpp mode you really
want.
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...@tr...> - 2001-06-13 16:36:12
|
> mmm, well, the problem is that most current 'millions of color' modes are in > truth depth 24 ones, which are internally either 32bpp (as in the permedia3 > case) or 24bpp (saves bandwith, but no alpha channel and you may be forced to > do some shifting). Ugh!!!! This is a bug in fbset. It shouldn't be called depth. It should be bpp. Depth is how the number of bits used to represent a color in a pixel. bpp is how many bits per pixel. A good example would be a card with a 80 bpp. Out of the 80 bpp only 30 are used for rbg space (10:10:10). The rest could be window IDs, depth buffer values etc. fbset should be using -bpp and you use -rgba to set the size of each field. Unfortunely the current fbdev api doesn't support things beyond RGBA in the buffer :-( > So what should happen if you try to set depth 24 with fbset ? Silently set 32 > bpp ? reject it ? > > Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or > rejected ? If we go by -depth really means -bpp then make it fail. If the user uses -rgba along with it then make it work. Some cards have the alpha channel as a seperate buffer. So these cards really have 24 bpp modes (8:8:8) where you have to use a seperate buffer to access the alpha channels. The same goes with cards with window IDs. Some have windows IDs interwoven with the framebuffer. Other do not. Here we don't even have a alpha channel. We still have 32 bpp but the depth is 24. The other 8 bits being a window ID value. BTW we could treat the alpha channel as another framebuffer with (0:0:0:8). Here with have a depth of 0 and bpp of 8. Right? Other types of buffers could be treated the same way as well. Again fbdev doesn't support this at present tho :-( That will have to change but this breaks backwards compatibility. > > > Also, i am experiencing some (maybe hardware) bugs, and would like to reset > > > the graphic chip. Is there an existing way to do this kind of stuff via ioctl > > > ore such (sure i could do it by hand under root, but i don't think fbcon/fbdev > > > would be really happy with it). > > > > Not really. You could make it reset the card when unloading the module. > > or when loading it ? Good point. loading it should reset the mode since you have to set up the card anyways with insmoding the driver. > Would it be possible to run the vga text console on one head, and a pm3fb on > the other ? (same chip). The hardware would have to support that. > Well, the real problem here is not so much to reset to default mode, but to do > a hardware reset on the chip, and initialize it again, to see if the problem > goes away. This is a problem for hardware that doesn't detect hardware faults. Some cards are smart enough to raise a interrupt when the accel engine goes bonkers. In the interrupt handler you reset the hardware to a sane state then. Does the pm2 card have such a feature? |
|
From: Geert U. <ge...@li...> - 2001-06-13 16:55:37
|
On Wed, 13 Jun 2001, James Simmons wrote:
> > So what should happen if you try to set depth 24 with fbset ? Silently set 32
> > bpp ? reject it ?
> >
> > Same goes for depth 15 ? should it silently be set to bpp 16, RGBA 5551, or
> > rejected ?
>
> If we go by -depth really means -bpp then make it fail. If the user uses
Wrong. The rules are to round a value up if it doesn't fit and if possible.
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...@tr...> - 2001-06-13 17:03:49
|
> > If we go by -depth really means -bpp then make it fail. If the user uses > > Wrong. The rules are to round a value up if it doesn't fit and if possible. So the basic approach is avoid failure at all cost :-) |
|
From: Sven L. <lu...@dp...> - 2001-06-14 10:57:07
|
On Wed, Jun 13, 2001 at 09:35:40AM -0700, James Simmons wrote: > > or when loading it ? > > Good point. loading it should reset the mode since you have to set up the > card anyways with insmoding the driver. > > > Would it be possible to run the vga text console on one head, and a pm3fb on > > the other ? (same chip). > > The hardware would have to support that. huh ??? What special hardware support is needed there. The card is just a multi function agp board, with both pm# having their own mmio and fb space, as well as the (unused by fbdev) gamma bridge. It is just like a dual card setup. Is there a hardware reason you cannot keep vgacon on the first head, and have fbcon setting up a new console on the second head ? I guess it is more limited by the software, isn't it ? Is it possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ? > > Well, the real problem here is not so much to reset to default mode, but to do > > a hardware reset on the chip, and initialize it again, to see if the problem > > goes away. > > This is a problem for hardware that doesn't detect hardware faults. Some > cards are smart enough to raise a interrupt when the accel engine goes > bonkers. In the interrupt handler you reset the hardware to a sane state > then. Does the pm2 card have such a feature? mmm, don't think so, will have to check it. But the problem is, i think, that thec chip don't really knows that something is going wrong. Friendly, Sven Luther > |
|
From: James S. <jsi...@tr...> - 2001-06-14 16:30:13
|
> huh ??? > > What special hardware support is needed there. The card is just a multi > function agp board, with both pm# having their own mmio and fb space, as well > as the (unused by fbdev) gamma bridge. This is what I mean. The card has to have two fully functional framebuffers, mmio regions and seperate accel engines if used. In a nut shell the hardware has to have two independent states. > It is just like a dual card setup. Is there a hardware reason you cannot keep > vgacon on the first head, and have fbcon setting up a new console on the > second head ? If the card can support being in a vga text state and a graphics state at the same time then I see no problem. > I guess it is more limited by the software, isn't it ? Is it > possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ? Not with 2.4.X :-( The console system uses a gloal struct consw (conswitchp). You really have to hack up the console system to get it to work. For me I just rewrote the whole thing. For ruby it is possible but I haven't done it yet. The biggest problem right now is the current vgacon I have. Lots of global variables. I like to be able to pass the register region and the text memory region to vgacon. By default they would be 0x3C0 for the registers and A000 for the text memory region. Well something like that. These regions are different on different platforms. Now you could write a small wrapper that passes in the pci regions. This is what I plan to do for the NVIDIA text mode driver I have. It pretty much is vgacon except it uses the pci regions instead. I also plan to vgacon firmware independent as well. As for your case it would be a matter of coordinating both pm3con and pm3fb together. They have to have the same initialization function to ensure the correct regions go to the correct console display drivers. > > then. Does the pm2 card have such a feature? > > mmm, don't think so, will have to check it. But the problem is, i think, that > thec chip don't really knows that something is going wrong. Some cards can tell if something does go wrong. A example is the ATI cards. They send out a irq when the accel engine goes bonkers. It is really for debugging but I can see its use otherwise. Imagine a X server ontop of ati fbdev and if the X server does something foolish then the kernel driver would correct itself. This would be a really nice feature. Plus you get the bonus info in syslog if you use printk to let you know something went wrong. |
|
From: Geert U. <ge...@li...> - 2001-06-13 16:06:09
|
On Wed, 13 Jun 2001, James Simmons wrote:
> > So i suppose saying fbset -depth 15 could be done to switch the fb to
> > RGBA5551 mode ?
> >
> > BTW, what is fbset -depth 24 supposed to do, especially if the chip only
> > support 8, 16, and 32 bpp ?
>
> fb_set_var should be done in two parts. The first part checks the purposed
> var and sees if the hardware can support it. The second part should set
> the resolution if the mode is supported. This is what I have done for the
> new api. Basically we have something like this:
>
> int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
> {
> int oldbpp, err;
>
> if (memcmp(&info->var, var, sizeof(var))) {
> if ((err = info->fbops->fb_check_var(var, info)))
> return err;
This is not correct, since it first overwrites the old var, then checks whether
the new one is valid. If that test fails, you're left with an invalid var in
info->var.
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...@tr...> - 2001-06-13 16:15:25
|
> > int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
> > {
> > int oldbpp, err;
> >
> > if (memcmp(&info->var, var, sizeof(var))) {
> > if ((err = info->fbops->fb_check_var(var, info)))
> > return err;
>
> This is not correct, since it first overwrites the old var, then checks whether
> the new one is valid. If that test fails, you're left with an invalid var in
> info->var.
That is a memory compare. It checks to see if the purposed mode is the
same as the current mode. If not then fb_check_var is called to test the
new var. info->var = var only if var->activate == FB_ACTIVATE_NOW and
their is a set_par function. You can set info->var = *var before set_par
is called because we trust check_var did its job.
|
|
From: Geert U. <ge...@li...> - 2001-06-13 16:23:19
|
On Wed, 13 Jun 2001, James Simmons wrote:
> > > int fb_set_var(struct fb_var_screeninfo *var, struct fb_info *info)
> > > {
> > > int oldbpp, err;
> > >
> > > if (memcmp(&info->var, var, sizeof(var))) {
> > > if ((err = info->fbops->fb_check_var(var, info)))
> > > return err;
> >
> > This is not correct, since it first overwrites the old var, then checks whether
> > the new one is valid. If that test fails, you're left with an invalid var in
> > info->var.
>
> That is a memory compare. It checks to see if the purposed mode is the
> same as the current mode. If not then fb_check_var is called to test the
> new var. info->var = var only if var->activate == FB_ACTIVATE_NOW and
> their is a set_par function. You can set info->var = *var before set_par
> is called because we trust check_var did its job.
Sorry, my twisted mind read memcpy() instead of memcmp().
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...@tr...> - 2001-06-13 16:46:23
|
> Sorry, my twisted mind read memcpy() instead of memcmp(). No problem. Been their, done that. |
×
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