[Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Paulius Zaleckas]

Hi,

On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation:

int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
[...]
if (var->pixclock == -1 || !var->pixclock)
return -EINVAL;
[...]

int drm_fb_helper_set_par(struct fb_info *info)
{
[...]
if (var->pixclock != -1) {
DRM_ERROR("PIXEL CLCOK SET\n");
return -EINVAL;
}
[...]

One of these evaluations will fail regardless of pixclock value.

P.S. check CLCOK spelling :)

[Clemens Ladisch]

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation: ...
P.S. check CLCOK spelling :)

This patch got lost during fb helper reorganization:
http://git.kernel.org/linus/1bcbf3948876e31a8ece28597dec447611ad9c8b


Regards,
Clemens

[James Simmons]

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation: ...

Those patches will enable fbdev apps to run properly. More patches are
needed if you want to support mode switching using the fbdev emulation
layer. I noticed my patches and yours where lost. Who do you send patches
too that can merge them ?

[Andrew Morton]

On Fri, 20 Nov 2009 18:53:37 +0000 (GMT)

Post by James Simmons

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation: ...

Those patches will enable fbdev apps to run properly. More patches are
needed if you want to support mode switching using the fbdev emulation
layer. I noticed my patches and yours where lost. Who do you send patches
too that can merge them ?

y:/usr/src/git26> perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c
David Airlie <***@linux.ie>
Dave Airlie <***@redhat.com>
Jesse Barnes <***@virtuousgeek.org>
Mikael Pettersson <***@it.uu.se>
dri-***@lists.sourceforge.net
linux-***@vger.kernel.org

That's accurate enough.

Generally, if nothing has happened in a week, the chances that it's
lost are very high. Resend. If you like, cc me and I'll maintain the patches
and resend them for you.

cheers,
lkml resendbot.

[Paulius Zaleckas]

Post by Andrew Morton
On Fri, 20 Nov 2009 18:53:37 +0000 (GMT)

Post by James Simmons

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation: ...

Those patches will enable fbdev apps to run properly. More patches are
needed if you want to support mode switching using the fbdev emulation
layer. I noticed my patches and yours where lost. Who do you send patches
too that can merge them ?

y:/usr/src/git26> perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c
That's accurate enough.
Generally, if nothing has happened in a week, the chances that it's
lost are very high. Resend. If you like, cc me and I'll maintain the patches
and resend them for you.

You can add Tested-by: Paulius Zaleckas <***@gmail.com>
for http://www.mail-archive.com/dri-***@lists.sourceforge.net/msg44369.html
as this was preventing DirectFB from running on my Asus Eee PC 701.

While at this patch maybe you should fix that spelling issue as well.

Post by Andrew Morton
cheers,
lkml resendbot.

[James Simmons]

Post by Paulius Zaleckas

Post by Andrew Morton

Post by James Simmons

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation: ...

Those patches will enable fbdev apps to run properly. More patches are
needed if you want to support mode switching using the fbdev emulation
layer. I noticed my patches and yours where lost. Who do you send patches
too that can merge them ?

y:/usr/src/git26> perl scripts/get_maintainer.pl -f
drivers/gpu/drm/drm_fb_helper.c
That's accurate enough.
Generally, if nothing has happened in a week, the chances that it's
lost are very high. Resend. If you like, cc me and I'll maintain the patches
and resend them for you.

as this was preventing DirectFB from running on my Asus Eee PC 701.

I tested it as well with the both my 3Dfx driver that I wrote with KMS and
the nouveau driver. We just need to make sure that the patches end up in
the drm-next tree or these patches will be lost when drm-next gets merged
to linus tree.

[Paulius Zaleckas]

Post by James Simmons

Post by Paulius Zaleckas

Post by James Simmons

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation: ...

Those patches will enable fbdev apps to run properly. More patches are
needed if you want to support mode switching using the fbdev emulation
layer. I noticed my patches and yours where lost. Who do you send patches
too that can merge them ?

y:/usr/src/git26> perl scripts/get_maintainer.pl -f
drivers/gpu/drm/drm_fb_helper.c
That's accurate enough.
Generally, if nothing has happened in a week, the chances that it's
lost are very high. Resend. If you like, cc me and I'll maintain the patches
and resend them for you.

as this was preventing DirectFB from running on my Asus Eee PC 701.

I tested it as well with the both my 3Dfx driver that I wrote with KMS and
the nouveau driver. We just need to make sure that the patches end up in
the drm-next tree or these patches will be lost when drm-next gets merged
to linus tree.

IMHO this patch should end up in current (2.6.32) kernel and we should
send it to stable ML.

[James Simmons]

Post by Paulius Zaleckas

Post by James Simmons

Post by Paulius Zaleckas

Post by James Simmons

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
video mode, because of different var->pixclock evaluation: ...

Those patches will enable fbdev apps to run properly. More patches are
needed if you want to support mode switching using the fbdev emulation
layer. I noticed my patches and yours where lost. Who do you send patches
too that can merge them ?

y:/usr/src/git26> perl scripts/get_maintainer.pl -f
drivers/gpu/drm/drm_fb_helper.c
That's accurate enough.
Generally, if nothing has happened in a week, the chances that it's
lost are very high. Resend. If you like, cc me and I'll maintain the patches
and resend them for you.

for
as this was preventing DirectFB from running on my Asus Eee PC 701.

I tested it as well with the both my 3Dfx driver that I wrote with KMS and
the nouveau driver. We just need to make sure that the patches end up in
the drm-next tree or these patches will be lost when drm-next gets merged
to linus tree.

IMHO this patch should end up in current (2.6.32) kernel and we should
send it to stable ML.

Honestly I like to see it there as well.

[Dave Airlie]

Post by James Simmons

Post by Paulius Zaleckas

Post by James Simmons

Post by Paulius Zaleckas

Post by James Simmons

Post by Paulius Zaleckas
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
video mode, because of different var->pixclock evaluation: ...

Those patches will enable fbdev apps to run properly. More patches are
needed if you want to support mode switching using the fbdev emulation
layer. I noticed my patches and yours where lost. Who do you send patches
too that can merge them ?

y:/usr/src/git26>   perl scripts/get_maintainer.pl -f
drivers/gpu/drm/drm_fb_helper.c
That's accurate enough.
Generally, if nothing has happened in a week, the chances that it's
lost are very high.  Resend.  If you like, cc me and I'll maintain the
patches
and resend them for you.

for
as this was preventing DirectFB from running on my Asus Eee PC 701.

I tested it as well with the both my 3Dfx driver that I wrote with KMS and
the nouveau driver. We just need to make sure that the patches end up in
the drm-next tree or these patches will be lost when drm-next gets merged
to linus tree.

IMHO this patch should end up in current (2.6.32) kernel and we should
send it to stable ML.

Honestly I like to see it there as well.

I have them queued for drm-next already at least locally, I wasn't aware
they were suitable for final, I didn't get a chance to really test them until
last week and make sure they didn't hide any side effects. I can
ask for them to go to stable when the merge window opens, I think
its too late for final.

Dave.

[Dave Airlie]

On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas

Post by Paulius Zaleckas
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
                           struct fb_info *info)
{
[...]
       if (var->pixclock == -1 || !var->pixclock)
               return -EINVAL;
[...]
int drm_fb_helper_set_par(struct fb_info *info)
{
[...]
       if (var->pixclock != -1) {
               DRM_ERROR("PIXEL CLCOK SET\n");
               return -EINVAL;
       }
[...]
One of these evaluations will fail regardless of pixclock value.

At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two heads and set native modes on both,

Now if a user runs fbset, I'm not sure what the right answer is,
a) pick a head in advance via sysfs maybe and set it on that.
b) try and set the mode on both heads cloned (what to do if
there is no common mode is another issue).

Dave.

[James Simmons]

Post by Dave Airlie
At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two heads and set native modes on both,

Does that mean that fbset is supposed to work (set resolution) on drmfb?

No we've never hooked it up but it could be made work.

I had it to the point of almost working. I plan on working on getting it
working again.

Schemes which would make a multihead setup look like a single screen
get complicated quite easily. Perhaps an option to turn off some
outputs so that the native resolution of one output is used (instead
of clone) would work.

(a) hook up another /dev/dri/card_fb device and use the current KMS
ioctls to control the framebuffer, have the drm callback into fbdev/fbcon
to mention resizes etc. Or add one or two info gathering ioctls and
allow use of the /dev/dri/control device to control stuff.
(b) add a lot of ioctls to KMS fbdev device, which implement some sort
of sane multi-output settings.
Now the second sounds like a lot of work if not the correct solution,
you basically needs a way to pretty much expose what the KMS ioctls
expose on the fb device, and then upgrade fbset to make sense of it all.

Yuck. See my other post about what fbdev really means in its historical
context. The struct fb_info really maps better to drm_crtc than to
drm_framebuffer. In fact take the case of the matrox fbdev driver. It
creates two framebuffer devices even tho it used one static framebuffer.
What the driver does is splits the framebuffer in two and assigned each
part to a CRTC.

[James Simmons]

Post by James Simmons
Yuck. See my other post about what fbdev really means in its historical
context. The struct fb_info really maps better to drm_crtc than to
drm_framebuffer. In fact take the case of the matrox fbdev driver. It
creates two framebuffer devices even tho it used one static framebuffer.
What the driver does is splits the framebuffer in two and assigned each
part to a CRTC.

The only problem with that is that it eats a lot of memory for the
console which limits X when it starts. On cards with limited vram ,
you might not have enough memory left for any meaningful acceleration
when X starts.

It would be nice to find a way to reclaim the console memory for X,
but I'm not sure that can be done and still provide a good way to
provide oops support.

Ah, the power of flags. We had the same issue with user requesting a mode
change or fbcon asking for a different mode. We handled it with the flag
FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will
have to deal also with the ability to change the resolution with tools like stty.
I can easily see how to do this plus give you more memory like you want :-)
For the oops are you talking about printing oops to the screen
while X is running ? Otherwise if you experience a oops and go back to
console mode you should be able to view it. The console text buffer is
independent of the graphics card memory system.

[James Simmons]

Post by James Simmons
Yuck. See my other post about what fbdev really means in its historical
context. The struct fb_info really maps better to drm_crtc than to
drm_framebuffer. In fact take the case of the matrox fbdev driver. It
creates two framebuffer devices even tho it used one static framebuffer.
What the driver does is splits the framebuffer in two and assigned each
part to a CRTC.

So you get the layering naturally. On fbset - fbev layer you can
choose from the resolutions available in the current output setup, in
kmset or whatever - drm layer you can set up the outputs, merge
multiple outputs into single cloned fbdev or separate them, ..
It's obviously nice if you can set the resolution on all of fbcons,
fbdev and drm layers but getting it work on at least one layer with
proper propagation up and down also works. BTW I don't know any
application which sets linux console (or xterm for that matter)
resolution through the terminal API.

I agree. The mode setting should be done in one layer. Its a matter of
doing the proper emulation of the fbdev layer.

[James Simmons]

It would be nice to find a way to reclaim the console memory for X,
but I'm not sure that can be done and still provide a good way to
provide oops support.

What do you think the average user will care about more?
     * Seeing kernel oops/panic output about once in a lifetime.
     * Being able to start/use X in the first place and enabling it to
       use all of VRAM.
Personally, I've never even seen any kernel oops/panic output despite
numerous opportunities for that in the couple of months I've been using
KMS. But I have spent considerable time and effort trying to get rid of
the pinned fbcon BO. If the oops/panic output is the only thing
preventing that, maybe that should only be enabled via some module
option for developers.

I'm all for it!

I'm looking into the details for this. It will require some changes to
internal apis to make it to work.

[James Simmons]

Post by James Simmons

It would be nice to find a way to reclaim the console memory for X,
but I'm not sure that can be done and still provide a good way to
provide oops support.

What do you think the average user will care about more?
     * Seeing kernel oops/panic output about once in a lifetime.
     * Being able to start/use X in the first place and enabling it to
       use all of VRAM.
Personally, I've never even seen any kernel oops/panic output despite
numerous opportunities for that in the couple of months I've been using
KMS. But I have spent considerable time and effort trying to get rid of
the pinned fbcon BO. If the oops/panic output is the only thing
preventing that, maybe that should only be enabled via some module
option for developers.

I'm all for it!

I'm looking into the details for this. It will require some changes to
internal apis to make it to work.

Can't it print the oops on whatever is currently displayed?
It need not be a dedicated buffer as long as there is always some buffer.
But perhaps this is more complex than that.

Yes it is very complex. Reading the code and drm specs you come to
realize buffer handling is done with GEM, TTM, or for older drivers drm_maps.
Drivers often handle a combine of those, meaning no real wrapper from one

[James Simmons]

Can't it print the oops on whatever is currently displayed?
It need not be a dedicated buffer as long as there is always some buffer.
But perhaps this is more complex than that.

       Yes it is very complex. Reading the code and drm specs you come to
realize buffer handling is done with GEM, TTM, or for older drivers drm_maps.
Drivers often handle a combine of those, meaning no real wrapper from one