Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2001-06-14 17:13:24
|
On 14 Jun 01 at 9:44, James Simmons wrote:
> Okay. I realize rounding up is also good for color depth changes.
> Someone could pass in a color depth of 12. We can easily fudge this to
> something that is supported.
>
> NOTE: If this is the case then most drivers are broken!!!!
Yes, that is why I asked whether someone knows driver which conforms
to API...
> They return a error instead. Also what is the policy for cards that can't
> change modes. Right now most drivers return a -EINVAL if they can't change
> a mode. Do we pass back the only mode the driver supports instead of
> returning a error?
If your vesafb runs in 1280x1024x32, setting 800x600x8 must
succeed, but do nothing. If it runs in 1280x1024x8, and you want
800x600x32, it must return error as 32 > 8! I still think that we should
use highest possible value instead of returning error when we cannot
round some value up to next possible value. For example vyres comes
to my (and matroxfb) mind ;-)
Petr Vandrovec
van...@vc...
|
|
From: Petr V. <VAN...@vc...> - 2001-06-14 17:49:49
|
On 14 Jun 01 at 10:46, James Simmons wrote:
> > > They return a error instead. Also what is the policy for cards that can't
> > > change modes. Right now most drivers return a -EINVAL if they can't change
> > > a mode. Do we pass back the only mode the driver supports instead of
> > > returning a error?
> >
> > If your vesafb runs in 1280x1024x32, setting 800x600x8 must
> > succeed, but do nothing.
>
> So a userland app would assume the video mode is 800x600x8 since it worked
> and was passed back it. Of course the results on the screen would be
> totally wrong. Then how is a userland app to know what the real mode is?
No. fb_set_var must return 1280x1024x32... (argument to fb_set_var
is not const...). Of course I know no app which verifies what
fb_set_var really did - but it is another problem.
Petr
|
|
From: James S. <jsi...@tr...> - 2001-06-14 20:01:28
|
> > So a userland app would assume the video mode is 800x600x8 since it worked > > and was passed back it. Of course the results on the screen would be > > totally wrong. Then how is a userland app to know what the real mode is? > > No. fb_set_var must return 1280x1024x32... (argument to fb_set_var > is not const...). Of course I know no app which verifies what > fb_set_var really did - but it is another problem. Sorry. Misunderstood you. As for apps which don't check the mode. Well they are broken. |
|
From: James S. <jsi...@tr...> - 2001-06-14 17:46:22
|
> > NOTE: If this is the case then most drivers are broken!!!! > > Yes, that is why I asked whether someone knows driver which conforms > to API... Off the top of my head vfb.c. I have to go threw the other drivers to see which one are correct and which are wrong :-( > > They return a error instead. Also what is the policy for cards that can't > > change modes. Right now most drivers return a -EINVAL if they can't change > > a mode. Do we pass back the only mode the driver supports instead of > > returning a error? > > If your vesafb runs in 1280x1024x32, setting 800x600x8 must > succeed, but do nothing. So a userland app would assume the video mode is 800x600x8 since it worked and was passed back it. Of course the results on the screen would be totally wrong. Then how is a userland app to know what the real mode is? > I still think that we should > use highest possible value instead of returning error when we cannot > round some value up to next possible value. For example vyres comes > to my (and matroxfb) mind ;-) I agree. This will especially be true when we support i2c to get monitor info. Here will will be fudging the hslen etc for the best fit. |
|
From: Geert U. <ge...@li...> - 2001-06-14 17:52:49
|
On Thu, 14 Jun 2001, James Simmons wrote:
> > > They return a error instead. Also what is the policy for cards that can't
> > > change modes. Right now most drivers return a -EINVAL if they can't change
> > > a mode. Do we pass back the only mode the driver supports instead of
> > > returning a error?
> >
> > If your vesafb runs in 1280x1024x32, setting 800x600x8 must
> > succeed, but do nothing.
>
> So a userland app would assume the video mode is 800x600x8 since it worked
> and was passed back it. Of course the results on the screen would be
> totally wrong. Then how is a userland app to know what the real mode is?
Vesafb should return the 1280x1024x32 mode.
> > I still think that we should
> > use highest possible value instead of returning error when we cannot
> > round some value up to next possible value. For example vyres comes
> > to my (and matroxfb) mind ;-)
>
> I agree. This will especially be true when we support i2c to get monitor
> info. Here will will be fudging the hslen etc for the best fit.
Sounds reasonable. The question is: will it break many things?
The other thing that will break things is changing pixclock from ps to MHz...
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-14 20:08:20
|
> Vesafb should return the 1280x1024x32 mode. But only if the asked mode is "smaller" than the defualt mode. > > I agree. This will especially be true when we support i2c to get monitor > > info. Here will will be fudging the hslen etc for the best fit. > > Sounds reasonable. The question is: will it break many things? I don't see why it would. You ask for a mode. The monitor can't handle it so we return -EINVAL. If the mode can be rounded up to something that the monitor can support than we return the var in fb_set_var. > The other thing that will break things is changing pixclock from ps to MHz... But of course. The default behavior should stay. In the fb_fix_screeninfo field we add a api_version id. For old programs this will be zero. For newer programs we can have them check this value and behave accordly. I provided the macros to convert from one to the other in fb.h in my CVS already. Should we wait for 2.5.X? P.S With a new fb filesystem this will allow use to work on a new api :-) Plus a device filesystem will give us much more flexiablity. Right now I don't have time to work on it but in the near future I will. |
|
From: Geert U. <ge...@li...> - 2001-06-15 07:51:58
|
On Thu, 14 Jun 2001, James Simmons wrote:
> > Vesafb should return the 1280x1024x32 mode.
>
> But only if the asked mode is "smaller" than the defualt mode.
Yes.
> > > I agree. This will especially be true when we support i2c to get monitor
> > > info. Here will will be fudging the hslen etc for the best fit.
> >
> > Sounds reasonable. The question is: will it break many things?
>
> I don't see why it would. You ask for a mode. The monitor can't handle it
> so we return -EINVAL. If the mode can be rounded up to something that the
^^^^^^^^^^^^^^^^^
> monitor can support than we return the var in fb_set_var.
Ah, here you say `rounded up'. In the mail I replied to you (and Petr) were
talking about finding suitable color bitfield lengths, allowing rounding down
as well.
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-15 15:47:48
|
> > I don't see why it would. You ask for a mode. The monitor can't handle it > > so we return -EINVAL. If the mode can be rounded up to something that the > ^^^^^^^^^^^^^^^^^ > > monitor can support than we return the var in fb_set_var. > > Ah, here you say `rounded up'. In the mail I replied to you (and Petr) were > talking about finding suitable color bitfield lengths, allowing rounding down > as well. So is round down is allowable as well? |
|
From: Geert U. <ge...@li...> - 2001-06-15 16:39:47
|
On Fri, 15 Jun 2001, James Simmons wrote:
> > > I don't see why it would. You ask for a mode. The monitor can't handle it
> > > so we return -EINVAL. If the mode can be rounded up to something that the
> > ^^^^^^^^^^^^^^^^^
> > > monitor can support than we return the var in fb_set_var.
> >
> > Ah, here you say `rounded up'. In the mail I replied to you (and Petr) were
> > talking about finding suitable color bitfield lengths, allowing rounding down
> > as well.
>
> So is round down is allowable as well?
No, but it was suggested that just changing the color bitfields to acceptable
values (this can involve rounding up or down) could be acceptable.
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-15 19:17:23
|
> No, but it was suggested that just changing the color bitfields to acceptable > values (this can involve rounding up or down) could be acceptable. Okay. |
|
From: Geert U. <ge...@li...> - 2001-06-15 07:54:06
|
On Thu, 14 Jun 2001, James Simmons wrote:
> > The other thing that will break things is changing pixclock from ps to MHz...
>
> But of course. The default behavior should stay. In the fb_fix_screeninfo
> field we add a api_version id. For old programs this will be zero. For
> newer programs we can have them check this value and behave accordly. I
> provided the macros to convert from one to the other in fb.h in my CVS
> already. Should we wait for 2.5.X?
Alternatively, what about putting the pixclock in MHz in a new field in var?
For old applications, it will be zero. So the fbdev can distinguish between old
and new behavior, and it should return both the old (ps) and new (MHz)
pixclock fields.
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-15 15:48:44
|
> Alternatively, what about putting the pixclock in MHz in a new field in var? > For old applications, it will be zero. So the fbdev can distinguish between old > and new behavior, and it should return both the old (ps) and new (MHz) > pixclock fields. Perhaps we should leave userspace stuff alone until we develope the fbdev filesystem. Their we will have a clean start. |
|
From: <dol...@cl...> - 2001-06-14 17:51:25
|
> Yes, that is why I asked whether someone knows driver which conforms > to API... If you mean "round up depth to something usable", then pm3fb does, and the driver the code I use come from (pm2fb, likely) does it too. They simply round up to the nearest multiple-of-8 (that will change in pm3fb, as 15 will be converted to 16-with-RGB555). Mmmm, know that I think of it, 17-24 will roud up to 24 and fails as 24bpp isn't supported (only 32bppp RGBA8888 is). -- Romain DOLBEAU ENS Cachan / Ker Lann Thesard IRISA / CAPS dol...@cl... |
|
From: James S. <jsi...@tr...> - 2001-06-14 20:02:36
|
> Mmmm, know that I think of it, 17-24 will roud up to 24 and fails as > 24bpp isn't supported (only 32bppp RGBA8888 is). I think roundup means up to the nears working mode. Youo have to make sure your check_var function would do the right thing. |
|
From: Romain D. <do...@ir...> - 2001-06-15 08:28:56
|
James Simmons wrote: > I think roundup means up to the nears working mode. Yep, it's a bug. And an easily fixed one, cool :-) > Youo have to make sure > your check_var function would do the right thing. I don't have a 'check_var'. It's vanilla 2.2/2.4 fbcon (using fbgen, no less ;-) I'll port to Ruby as soon as BenH update his PPC tree to 2.4.5+ (2.4.5pre3-* hasn't all the required symbol for current Ruby, and 2.4.5-linus doesn't compile on my box...) -- 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-15 17:47:42
|
> > Youo have to make sure > > your check_var function would do the right thing. > > I don't have a 'check_var'. It's vanilla 2.2/2.4 > fbcon (using fbgen, no less ;-) No problem. I will have a patch for a wrapper soon. > I'll port to Ruby as soon as BenH update his PPC > tree to 2.4.5+ (2.4.5pre3-* hasn't all the required > symbol for current Ruby, and 2.4.5-linus doesn't > compile on my box...) Never been tested on a PPC. This will be interesting:-) |
|
From: Sven L. <lu...@dp...> - 2001-06-15 10:19:58
|
On Thu, Jun 14, 2001 at 07:51:30PM +0200, Romain Dolbeau wrote: > > Yes, that is why I asked whether someone knows driver which conforms > > to API... > > If you mean "round up depth to something usable", then pm3fb does, and > the driver the code I use come from (pm2fb, likely) does it too. They > simply round up to the nearest multiple-of-8 (that will change in pm3fb, > as 15 will be converted to 16-with-RGB555). > > Mmmm, know that I think of it, 17-24 will roud up to 24 and fails as > 24bpp isn't supported (only 32bppp RGBA8888 is). simply round depth 24 to 32, as it is the same thing anyway, except for the missing alpha channel. Friendly, Sven Luther |
×
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