Menu
▾
▴
linux-fbdev-devel
|
From: James S. <jsi...@tr...> - 2001-06-14 16:44:59
|
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!!!! 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? |
|
From: Geert U. <ge...@li...> - 2001-06-14 17:47:59
|
On Thu, 14 Jun 2001, 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!!!!
Yep. Few (if any) drivers follow the rules 100%.
> 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 you can't change modes, the rule is still to round up, if possible. So if
you try a mode where all parameters <= the only one supported mode, then you
should return the only one supported mode. Else you should return -EINVAL.
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 19:59:55
|
> > NOTE: If this is the case then most drivers are broken!!!! > > Yep. Few (if any) drivers follow the rules 100%. So I have noticed :-( > If you can't change modes, the rule is still to round up, if possible. So if > you try a mode where all parameters <= the only one supported mode, then you > should return the only one supported mode. Else you should return -EINVAL. All the parameters? This makes for a meaty checking function. |
|
From: Geert U. <ge...@li...> - 2001-06-15 07:50:20
|
On Thu, 14 Jun 2001, James Simmons wrote:
> > > NOTE: If this is the case then most drivers are broken!!!!
> >
> > Yep. Few (if any) drivers follow the rules 100%.
>
> So I have noticed :-(
>
> > If you can't change modes, the rule is still to round up, if possible. So if
> > you try a mode where all parameters <= the only one supported mode, then you
> > should return the only one supported mode. Else you should return -EINVAL.
>
> All the parameters? This makes for a meaty checking function.
Yes, I've been thinking about providing a `staticfb' core for drivers that
support one video mode only. Vesafb and offb (and a few of the PA-RISC drivers
IIRC) can be build on top of that, with minimal additional code.
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:45:28
|
> > > If you can't change modes, the rule is still to round up, if possible. So if > > > you try a mode where all parameters <= the only one supported mode, then you > > > should return the only one supported mode. Else you should return -EINVAL. > > > > All the parameters? This makes for a meaty checking function. > > Yes, I've been thinking about providing a `staticfb' core for drivers that > support one video mode only. Vesafb and offb (and a few of the PA-RISC drivers > IIRC) can be build on top of that, with minimal additional code. Guess what. I already have something like this in the console CVS. sfb.c (Simple frame buffer device). It needs some work tho. Also I pretty much have made every function in fb_ops a option. |
|
From: Geert U. <ge...@li...> - 2001-06-15 16:40:22
|
On Fri, 15 Jun 2001, James Simmons wrote:
> > > > If you can't change modes, the rule is still to round up, if possible. So if
> > > > you try a mode where all parameters <= the only one supported mode, then you
> > > > should return the only one supported mode. Else you should return -EINVAL.
> > >
> > > All the parameters? This makes for a meaty checking function.
> >
> > Yes, I've been thinking about providing a `staticfb' core for drivers that
> > support one video mode only. Vesafb and offb (and a few of the PA-RISC drivers
> > IIRC) can be build on top of that, with minimal additional code.
>
> Guess what. I already have something like this in the console CVS. sfb.c
> (Simple frame buffer device). It needs some work tho. Also I pretty much
> have made every function in fb_ops a option.
OK, so vesafb and offb just don't fill in a set_var function, right?
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 17:36:43
|
> > Guess what. I already have something like this in the console CVS. sfb.c > > (Simple frame buffer device). It needs some work tho. Also I pretty much > > have made every function in fb_ops a option. > > OK, so vesafb and offb just don't fill in a set_var function, right? Pretty much. Or in the case of teh new api fb_check_var nor fb_set_par are needed. |
|
From: Brad D. <br...@ne...> - 2001-06-14 19:58:01
|
On 14 Jun 2001 09:44:56 -0700, 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. I thought we had discussed in the past that rounding was the accepted method. aty128fb rounds. Brad Douglas br...@ne... |
|
From: James S. <jsi...@tr...> - 2001-06-14 20:10:23
|
> I thought we had discussed in the past that rounding was the accepted > method. We did but I forgot about it with handling color depths. The good thing we clearified was handling non changable video modes. |
×
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