linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] mode change policy

[Geert U. <ge...@li...>]

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

Re: [Linux-fbdev-devel] 2.4 official API ?

[James S. <jsi...@tr...>]

> Disclaimer: I didn't do any Ruby driver yet. Atyfb is in my (long) todo bucket.
> 
> I _think_ you can nicely encapsulate a 2.5 style driver using a 2.4
> compatibility layer. Just add some stubs that take care of get_{var,fix}() and
> of the extra con argument.

Pretty much. The approach I toke was to write a fbcon-accel.c file much
like fbcon-cfbX and friends. I have it at home. It had one bug in it
which I need to fix. Since people are really interested in this wrapper I
will work on it this weekend along with docs. 

P.S
   One note to make. The only big difference between 2.4.X with the wrapper 
and ruby will be the ablilty to use DMA. The ruby tree can support cards
in DMA/irq mode whereas in 2.4.X you can't. This is due to the console_lock 
which Andrew Morton and I have rewritten to make possible DMA. Using DMA
will mean certain drivers (matrox and aty128) could be really difference
between ruby and 2.4.X even with the wrapper. 

Re: [Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

> 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.

Re: [Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

> > 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?

[Linux-fbdev-devel] Re: mode change policy

[James S. <jsi...@tr...>]

> > > 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.

Re: [Linux-fbdev-devel] mode change policy

[Sven L. <lu...@dp...>]

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

Re: [Linux-fbdev-devel] 2.4 official API ?

[Romain D. <do...@ir...>]

Ghozlane Toumi wrote:
> So the question is how do i support 2.2/2.4 *and* the upcomming 2.5 API
> without maintainig 3 separate sources : i have to work on the internals of
> the driver,
> and i don't feel like updating 3 files every time ...

Didn't yet try ruby, but 2.2/2.4 are extremely similar and
I have just one source file for pm3fb that cover both.
Changes are cosmetic, not functionnal (XXXfb_setup
return an int instead of void, THIS_MODULE as
the first element of XXXfb_ops...)

-- 
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

Re: [Linux-fbdev-devel] proper behavior with request_mem_region

[Geert U. <ge...@li...>]

On Fri, 15 Jun 2001, Romain Dolbeau wrote:
> pm3fb use the 'request_mem_region' to be a good citizen in
> the linux driver world. But I have a chicken-and-egg problem
> I just found out:
> 
> 1) if I detect memory *before* request_mem_region, I might
> write and read in conflicting memory space. That's what is
> done ATM.
> 
> 2) if I detect memory *after* request_mem_region, I must
> request the whole 64 MB of aperture space, just in case...
> 
> What is the proper behavior ? Or should I request 64 MB,
> detect memory, release 64 MB, request the real size ?

So the PCI resource is 64 MB large, but some boards may not be fully populated
with RAM? Then always request the full 64 MB.

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

Re: [Linux-fbdev-devel] 2.4 official API ?

[Geert U. <ge...@li...>]

On Fri, 15 Jun 2001, Ghozlane Toumi wrote:
> So the question is how do i support 2.2/2.4 *and* the upcomming 2.5 API
> without maintainig 3 separate sources : i have to work on the internals of
> the driver,
> and i don't feel like updating 3 files every time ...
> 
> any suggestions ?
> how do you guys cope with that ?

Disclaimer: I didn't do any Ruby driver yet. Atyfb is in my (long) todo bucket.

I _think_ you can nicely encapsulate a 2.5 style driver using a 2.4
compatibility layer. Just add some stubs that take care of get_{var,fix}() and
of the extra con argument.

Since these stubs have to be the same for each driver, what we need is some
include file that provides the compatibility layer, and some additional #ifdefs
I guess, or clever macros.

Is this correct, James?

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

Re: [Linux-fbdev-devel] 2.4 official API ?

[Ghozlane T. <gt...@pr...>]

----- Original Message -----
From: "James Simmons" <jsi...@tr...>
Subject: Re: [Linux-fbdev-devel] 2.4 official API ?


> It looks like to have to update FB-Driver-HOWTO.

yep .. may i suggest a chapter on the changes between 2.2. and 2.4 ,
and between 2.4 and the upcomming 2.5 API ?

> > is "vfb" up to date, and a good sample of what should be done ? or is it
> > skelettonfb ?
> Both should be updated. I can send a patch which also I hope encourages
> people to migrate to the new api. I like to thank Russell King for moving
> over the arm fbdev drivers to the new api. It makes my life easier :->

I'm for sure interested .

I'm trying to bet back to work on my fb driver (voodoo1 and now voodoo2
officialy almost supported) after letting it sleep for way too long .

I'm having a hard time trying to merge the cleanups/fixes added in
the ruby tree and keeping 2.2/2.4 compatibility ...

So the question is how do i support 2.2/2.4 *and* the upcomming 2.5 API
without maintainig 3 separate sources : i have to work on the internals of
the driver,
and i don't feel like updating 3 files every time ...

any suggestions ?
how do you guys cope with that ?

thanks,
ghoz

[Linux-fbdev-devel] proper behavior with request_mem_region

[Romain D. <do...@ir...>]

Hello,

pm3fb use the 'request_mem_region' to be a good citizen in
the linux driver world. But I have a chicken-and-egg problem
I just found out:

1) if I detect memory *before* request_mem_region, I might
write and read in conflicting memory space. That's what is
done ATM.

2) if I detect memory *after* request_mem_region, I must
request the whole 64 MB of aperture space, just in case...

What is the proper behavior ? Or should I request 64 MB,
detect memory, release 64 MB, request the real size ?

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

Re: [Linux-fbdev-devel] mode change policy

[Romain D. <do...@ir...>]

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

Re: [Linux-fbdev-devel] Re: [linux-fbdev] FB Visuals

[Geert U. <ge...@li...>]

On Fri, 15 Jun 2001, Petr Vandrovec wrote:
> On 14 Jun 01 at 23:06, Russell King wrote:
> > I've got some modifications coming into the ARM kernel tree concerning
> > ARM specific framebuffers for devices with 4 bpp greyscale (LCD).
> > 
> > What is the official way of handling 4bpp greyscale framebuffers?
> > They're currently using pseudocolor/static pseudocolor with
> > var->greyscale set to one, and translating this to the relevant
> > greyscale visual in their tinyX server.
> 
> I believe that it is correct one. PSEUDOCOLOR if you can reorder/change
> these gray levels and STATIC_PSEUDOCOLOR if it is just hardwired
> that 0 is black and 15 is white.

Exactly my answer.

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

Re: [Linux-fbdev-devel] mode change policy

[Geert U. <ge...@li...>]

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

Re: [Linux-fbdev-devel] mode change policy

[Geert U. <ge...@li...>]

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

[Linux-fbdev-devel] Re: mode change policy

[Geert U. <ge...@li...>]

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

[Linux-fbdev-devel] Re: [linux-fbdev] FB Visuals

[Petr V. <VAN...@vc...>]

On 14 Jun 01 at 23:06, Russell King wrote:

> I've got some modifications coming into the ARM kernel tree concerning
> ARM specific framebuffers for devices with 4 bpp greyscale (LCD).
> 
> What is the official way of handling 4bpp greyscale framebuffers?
> They're currently using pseudocolor/static pseudocolor with
> var->greyscale set to one, and translating this to the relevant
> greyscale visual in their tinyX server.

I believe that it is correct one. PSEUDOCOLOR if you can reorder/change
these gray levels and STATIC_PSEUDOCOLOR if it is just hardwired
that 0 is black and 15 is white.
                                        Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: [Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

> 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.

Re: [Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

> 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.

Re: [Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

> 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.

Re: [Linux-fbdev-devel] mode change policy

[James S. <jsi...@tr...>]

> > 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.

[Linux-fbdev-devel] Re: mode change policy

[James S. <jsi...@tr...>]

> > 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. 

Re: [Linux-fbdev-devel] mode change policy

[Brad D. <br...@ne...>]

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...

Re: [Linux-fbdev-devel] mode change policy

[Geert U. <ge...@li...>]

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

Re: [Linux-fbdev-devel] mode change policy

[<dol...@cl...>]

> 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...