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

[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 :)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[Clemens Ladisch]

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

patch:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html

> P.S. check CLCOK spelling :)

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


Regards,
Clemens

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[James Simmons]

> Paulius Zaleckas wrote:
> > On drivers using drm_fb_helper's in fb_ops it is not possible to change
> > video mode, because of different var->pixclock evaluation: ...
> 
> patch:
> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html

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 ?  
 

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

[Andrew Morton]

On Fri, 20 Nov 2009 18:53:37 +0000 (GMT)
James Simmons <jsimmons@infradead.org> wrote:

> 
> > Paulius Zaleckas wrote:
> > > On drivers using drm_fb_helper's in fb_ops it is not possible to change
> > > video mode, because of different var->pixclock evaluation: ...
> > 
> > patch:
> > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
> 
> 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 <airlied@linux.ie>
Dave Airlie <airlied@redhat.com>
Jesse Barnes <jbarnes@virtuousgeek.org>
Mikael Pettersson <mikpe@it.uu.se>
dri-devel@lists.sourceforge.net
linux-kernel@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.

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

[Paulius Zaleckas]

On 11/20/2009 09:05 PM, Andrew Morton wrote:
> On Fri, 20 Nov 2009 18:53:37 +0000 (GMT)
> James Simmons<jsimmons@infradead.org>  wrote:
>
>>
>>> Paulius Zaleckas wrote:
>>>> On drivers using drm_fb_helper's in fb_ops it is not possible to change
>>>> video mode, because of different var->pixclock evaluation: ...
>>>
>>> patch:
>>> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
>>
>> 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<airlied@linux.ie>
> Dave Airlie<airlied@redhat.com>
> Jesse Barnes<jbarnes@virtuousgeek.org>
> Mikael Pettersson<mikpe@it.uu.se>
> dri-devel@lists.sourceforge.net
> linux-kernel@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.

You can add Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
for http://www.mail-archive.com/dri-devel@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.

> cheers,
> lkml resendbot.

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

[James Simmons]

> > > > Paulius Zaleckas wrote:
> > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
> > > > > change
> > > > > video mode, because of different var->pixclock evaluation: ...
> > > > 
> > > > patch:
> > > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
> > > 
> > > 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<airlied@linux.ie>
> > Dave Airlie<airlied@redhat.com>
> > Jesse Barnes<jbarnes@virtuousgeek.org>
> > Mikael Pettersson<mikpe@it.uu.se>
> > dri-devel@lists.sourceforge.net
> > linux-kernel@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.
> 
> You can add Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
> for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
> 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.

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

[Paulius Zaleckas]

On 11/20/2009 10:01 PM, James Simmons wrote:
>
>>>>> Paulius Zaleckas wrote:
>>>>>> On drivers using drm_fb_helper's in fb_ops it is not possible to
>>>>>> change
>>>>>> video mode, because of different var->pixclock evaluation: ...
>>>>>
>>>>> patch:
>>>>> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
>>>>
>>>> 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<airlied@linux.ie>
>>> Dave Airlie<airlied@redhat.com>
>>> Jesse Barnes<jbarnes@virtuousgeek.org>
>>> Mikael Pettersson<mikpe@it.uu.se>
>>> dri-devel@lists.sourceforge.net
>>> linux-kernel@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.
>>
>> You can add Tested-by: Paulius Zaleckas<paulius.zaleckas@gmail.com>
>> for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
>> 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.

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

[James Simmons]

On Fri, 20 Nov 2009, Paulius Zaleckas wrote:

> On 11/20/2009 10:01 PM, James Simmons wrote:
> > 
> > > > > > Paulius Zaleckas wrote:
> > > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
> > > > > > > change
> > > > > > > video mode, because of different var->pixclock evaluation: ...
> > > > > > 
> > > > > > patch:
> > > > > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
> > > > > 
> > > > > 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<airlied@linux.ie>
> > > > Dave Airlie<airlied@redhat.com>
> > > > Jesse Barnes<jbarnes@virtuousgeek.org>
> > > > Mikael Pettersson<mikpe@it.uu.se>
> > > > dri-devel@lists.sourceforge.net
> > > > linux-kernel@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.
> > > 
> > > You can add Tested-by: Paulius Zaleckas<paulius.zaleckas@gmail.com>
> > > for
> > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
> > > 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.

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

[Dave Airlie]

On Sat, Nov 21, 2009 at 6:48 AM, James Simmons <jsimmons@infradead.org> wrote:
>
>
> On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
>
>> On 11/20/2009 10:01 PM, James Simmons wrote:
>> >
>> > > > > > Paulius Zaleckas wrote:
>> > > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
>> > > > > > > change
>> > > > > > > video mode, because of different var->pixclock evaluation: ...
>> > > > > >
>> > > > > > patch:
>> > > > > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
>> > > > >
>> > > > > 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<airlied@linux.ie>
>> > > > Dave Airlie<airlied@redhat.com>
>> > > > Jesse Barnes<jbarnes@virtuousgeek.org>
>> > > > Mikael Pettersson<mikpe@it.uu.se>
>> > > > dri-devel@lists.sourceforge.net
>> > > > linux-kernel@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.
>> > >
>> > > You can add Tested-by: Paulius Zaleckas<paulius.zaleckas@gmail.com>
>> > > for
>> > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
>> > > 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.

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

[Dave Airlie]

On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
<paulius.zaleckas@gmail.com> wrote:
> 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.
>

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.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[Michal Suchanek]

On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:

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

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

I would say it's time to support multihead with fbset properly.

That is people would need new fbset which sees both (all) heads, and
fbset can then choose the head itself (and people can make it do
something different when they don't like the default). It should also
support setting up rotation on each head.

For old fbset setting something visible is probably good enough.

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.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michal Suchanek]

On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:

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

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

I would say it's time to support multihead with fbset properly.

That is people would need new fbset which sees both (all) heads, and
fbset can then choose the head itself (and people can make it do
something different when they don't like the default). It should also
support setting up rotation on each head.

For old fbset setting something visible is probably good enough.

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.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Dave Airlie]

On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:
>
>> 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.

>
>>
>> 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).
>>
>
> I would say it's time to support multihead with fbset properly.
>
> That is people would need new fbset which sees both (all) heads, and
> fbset can then choose the head itself (and people can make it do
> something different when they don't like the default). It should also
> support setting up rotation on each head.
>
> For old fbset setting something visible is probably good enough.
>
> 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.
>

I've only really got two answer for this:

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

Dave.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Dave Airlie]

On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
> On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:
>
>> 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.

>
>>
>> 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).
>>
>
> I would say it's time to support multihead with fbset properly.
>
> That is people would need new fbset which sees both (all) heads, and
> fbset can then choose the head itself (and people can make it do
> something different when they don't like the default). It should also
> support setting up rotation on each head.
>
> For old fbset setting something visible is probably good enough.
>
> 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.
>

I've only really got two answer for this:

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

Dave.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michal Suchanek]

On 3 March 2010 06:02, Dave Airlie <airlied@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:
>>
>>> 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.
>
>>
>>>
>>> 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).
>>>
>>
>> I would say it's time to support multihead with fbset properly.
>>
>> That is people would need new fbset which sees both (all) heads, and
>> fbset can then choose the head itself (and people can make it do
>> something different when they don't like the default). It should also
>> support setting up rotation on each head.
>>
>> For old fbset setting something visible is probably good enough.
>>
>> 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.
>>
>
> I've only really got two answer for this:
>
> (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.
>

What about writing a drmfbset or something and have fbset call it when
it detects a drm framebuffer and warn that it does not support drm
framebuffers fully?

That way people using fbset still get something and people who want
exact control over the setup can use the new tool which uses whatever
KMS interface is available already.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michal Suchanek]

On 3 March 2010 06:02, Dave Airlie <airlied@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek <hramrach@centrum.cz> wrote:
>> On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:
>>
>>> 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.
>
>>
>>>
>>> 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).
>>>
>>
>> I would say it's time to support multihead with fbset properly.
>>
>> That is people would need new fbset which sees both (all) heads, and
>> fbset can then choose the head itself (and people can make it do
>> something different when they don't like the default). It should also
>> support setting up rotation on each head.
>>
>> For old fbset setting something visible is probably good enough.
>>
>> 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.
>>
>
> I've only really got two answer for this:
>
> (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.
>

What about writing a drmfbset or something and have fbset call it when
it detects a drm framebuffer and warn that it does not support drm
framebuffers fully?

That way people using fbset still get something and people who want
exact control over the setup can use the new tool which uses whatever
KMS interface is available already.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Dave Airlie]

>>
>>
>> I've only really got two answer for this:
>>
>> (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.
>>
>
> What about writing a drmfbset or something and have fbset call it when
> it detects a drm framebuffer and warn that it does not support drm
> framebuffers fully?
>

My main problem with calling the drm underneath the fbdev is it
seems like a layering violation. Then again some of code in the kernel
is also contributing to this violation. I'd really like to make fbdev more
like an in-kernel version of what X driver have to do, and leave all the
initial modepicking etc to the fbdev interface layer.

If we take  the layering as
fbcon -> fbdev -> kms -> hw

I feel calling ioctls on the KMS layer from userspace to do stuff for
fbcon or fbdev
is wrong, and we should rather expose a more intelligent set of ioctls via the
fbdev device node. This points at quite a bit of typing.

So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev
drivers do, and then a new fbset could tkae advantage of these. I'm not sure
how much different to the current kms interface or how powerful we really need
to make tihs interface though, and I feel kinda bad implementing it without
some idea what users would want from it.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Dave Airlie]

>>
>>
>> I've only really got two answer for this:
>>
>> (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.
>>
>
> What about writing a drmfbset or something and have fbset call it when
> it detects a drm framebuffer and warn that it does not support drm
> framebuffers fully?
>

My main problem with calling the drm underneath the fbdev is it
seems like a layering violation. Then again some of code in the kernel
is also contributing to this violation. I'd really like to make fbdev more
like an in-kernel version of what X driver have to do, and leave all the
initial modepicking etc to the fbdev interface layer.

If we take  the layering as
fbcon -> fbdev -> kms -> hw

I feel calling ioctls on the KMS layer from userspace to do stuff for
fbcon or fbdev
is wrong, and we should rather expose a more intelligent set of ioctls via the
fbdev device node. This points at quite a bit of typing.

So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev
drivers do, and then a new fbset could tkae advantage of these. I'm not sure
how much different to the current kms interface or how powerful we really need
to make tihs interface though, and I feel kinda bad implementing it without
some idea what users would want from it.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michal Suchanek]

On 3 March 2010 10:23, Dave Airlie <airlied@gmail.com> wrote:
>>>
>>>
>>> I've only really got two answer for this:
>>>
>>> (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.
>>>
>>
>> What about writing a drmfbset or something and have fbset call it when
>> it detects a drm framebuffer and warn that it does not support drm
>> framebuffers fully?
>>
>
> My main problem with calling the drm underneath the fbdev is it
> seems like a layering violation. Then again some of code in the kernel
> is also contributing to this violation. I'd really like to make fbdev more
> like an in-kernel version of what X driver have to do, and leave all the
> initial modepicking etc to the fbdev interface layer.
>
> If we take  the layering as
> fbcon -> fbdev -> kms -> hw
>
> I feel calling ioctls on the KMS layer from userspace to do stuff for
> fbcon or fbdev
> is wrong, and we should rather expose a more intelligent set of ioctls via the
> fbdev device node. This points at quite a bit of typing.

I don't think so. There is another driver which does this -
vesa/uvesa. For these it is not possible to change the resolution from
fbdev, it just provides some framebuffer on top of which fb
applications or fbcons run.

You set the proper options on the proper layer - fonts in fbcons,
resolution in fbdev or the driver (which sucks but so far nobody came
up with a modesetting solution universal enough to work with all
drivers), and some hardware-specific options in the driver as well.

Still if most framebuffer drivers are converted to KMS there would not
be interface discrepancies. KMS would be used to set resolution and
fbdev to draw on the screen.

>
> So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev
> drivers do, and then a new fbset could tkae advantage of these. I'm not sure
> how much different to the current kms interface or how powerful we really need
> to make tihs interface though, and I feel kinda bad implementing it without
> some idea what users would want from it.
>

I guess equivalent of xrandr would be what people would want but the
current fbdev capabilities are far from that.
Since KMS provides these capabilities already I would think adding a
tool that manipulates KMS directly (kmset?) is the simplest way.

There are other drivers that support multihead already (matroxfb, any
other?) and have their own driver-specific inteface.

Designing an unified multihead fbdev extension interface would
probably take quite a bit of typing and time. It would also help to
have something working to compare to.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Michal Suchanek]

On 3 March 2010 10:23, Dave Airlie <airlied@gmail.com> wrote:
>>>
>>>
>>> I've only really got two answer for this:
>>>
>>> (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.
>>>
>>
>> What about writing a drmfbset or something and have fbset call it when
>> it detects a drm framebuffer and warn that it does not support drm
>> framebuffers fully?
>>
>
> My main problem with calling the drm underneath the fbdev is it
> seems like a layering violation. Then again some of code in the kernel
> is also contributing to this violation. I'd really like to make fbdev more
> like an in-kernel version of what X driver have to do, and leave all the
> initial modepicking etc to the fbdev interface layer.
>
> If we take  the layering as
> fbcon -> fbdev -> kms -> hw
>
> I feel calling ioctls on the KMS layer from userspace to do stuff for
> fbcon or fbdev
> is wrong, and we should rather expose a more intelligent set of ioctls via the
> fbdev device node. This points at quite a bit of typing.

I don't think so. There is another driver which does this -
vesa/uvesa. For these it is not possible to change the resolution from
fbdev, it just provides some framebuffer on top of which fb
applications or fbcons run.

You set the proper options on the proper layer - fonts in fbcons,
resolution in fbdev or the driver (which sucks but so far nobody came
up with a modesetting solution universal enough to work with all
drivers), and some hardware-specific options in the driver as well.

Still if most framebuffer drivers are converted to KMS there would not
be interface discrepancies. KMS would be used to set resolution and
fbdev to draw on the screen.

>
> So we'd need to add a bunch of KMS fb specifc ioctl like some of the other fbdev
> drivers do, and then a new fbset could tkae advantage of these. I'm not sure
> how much different to the current kms interface or how powerful we really need
> to make tihs interface though, and I feel kinda bad implementing it without
> some idea what users would want from it.
>

I guess equivalent of xrandr would be what people would want but the
current fbdev capabilities are far from that.
Since KMS provides these capabilities already I would think adding a
tool that manipulates KMS directly (kmset?) is the simplest way.

There are other drivers that support multihead already (matroxfb, any
other?) and have their own driver-specific inteface.

Designing an unified multihead fbdev extension interface would
probably take quite a bit of typing and time. It would also help to
have something working to compare to.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[James Simmons]

> I don't think so. There is another driver which does this -
> vesa/uvesa. For these it is not possible to change the resolution from
> fbdev, it just provides some framebuffer on top of which fb
> applications or fbcons run.

Only because that is the only way to do it. The other options was to have 
x86emul in the kernel. That was not going to happen.
 
> I guess equivalent of xrandr would be what people would want but the
> current fbdev capabilities are far from that.
> Since KMS provides these capabilities already I would think adding a
> tool that manipulates KMS directly (kmset?) is the simplest way.

Still would have to deal with the issue of keeping the graphical console 
in sync with the changes.
 
> There are other drivers that support multihead already (matroxfb, any
> other?) and have their own driver-specific inteface.

Each crtc is treated as a seperate fbdev device. I don't recall any 
special ioctls. Maybe for mirroring which was never standardized.

> Designing an unified multihead fbdev extension interface would
> probably take quite a bit of typing and time. It would also help to
> have something working to compare to.

IMNSHO the fbdev to ctrc mapping should be the standard way to 
handle the fbdev layer. Plus it is a KISS approach. Mirroring would need 
to be finally dealt with.

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

[James Simmons]

> I don't think so. There is another driver which does this -
> vesa/uvesa. For these it is not possible to change the resolution from
> fbdev, it just provides some framebuffer on top of which fb
> applications or fbcons run.

Only because that is the only way to do it. The other options was to have 
x86emul in the kernel. That was not going to happen.
 
> I guess equivalent of xrandr would be what people would want but the
> current fbdev capabilities are far from that.
> Since KMS provides these capabilities already I would think adding a
> tool that manipulates KMS directly (kmset?) is the simplest way.

Still would have to deal with the issue of keeping the graphical console 
in sync with the changes.
 
> There are other drivers that support multihead already (matroxfb, any
> other?) and have their own driver-specific inteface.

Each crtc is treated as a seperate fbdev device. I don't recall any 
special ioctls. Maybe for mirroring which was never standardized.

> Designing an unified multihead fbdev extension interface would
> probably take quite a bit of typing and time. It would also help to
> have something working to compare to.

IMNSHO the fbdev to ctrc mapping should be the standard way to 
handle the fbdev layer. Plus it is a KISS approach. Mirroring would need 
to be finally dealt with.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Ville Syrjälä]

On Wed, Mar 10, 2010 at 06:11:29PM +0000, James Simmons wrote:
> 
> > I don't think so. There is another driver which does this -
> > vesa/uvesa. For these it is not possible to change the resolution from
> > fbdev, it just provides some framebuffer on top of which fb
> > applications or fbcons run.
> 
> Only because that is the only way to do it. The other options was to have 
> x86emul in the kernel. That was not going to happen.
>  
> > I guess equivalent of xrandr would be what people would want but the
> > current fbdev capabilities are far from that.
> > Since KMS provides these capabilities already I would think adding a
> > tool that manipulates KMS directly (kmset?) is the simplest way.
> 
> Still would have to deal with the issue of keeping the graphical console 
> in sync with the changes.
>  
> > There are other drivers that support multihead already (matroxfb, any
> > other?) and have their own driver-specific inteface.
> 
> Each crtc is treated as a seperate fbdev device. I don't recall any 
> special ioctls. Maybe for mirroring which was never standardized.

matroxfb does have a bunch of custom ioctls to change the crtc<->output
mapping. omapfb is another multihead fb driver and it's more complex
than matroxfb. Trying to make it perform various tricks through the
fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs)
is something I've been doing but I would not recommend it for anyone
who has the option of using a better API.

I don't think the CRTCû_info makes much sense if the main use
case is fbcon. fbcon will use a single fb device and so you can't see
the console on multiple heads anyway which makes the whole thing
somewhat pointless. And if you're trying to do something more complex
you will be a lot better off bypassing fbdev altogether.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

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

[Ville Syrjälä]

On Wed, Mar 10, 2010 at 06:11:29PM +0000, James Simmons wrote:
> 
> > I don't think so. There is another driver which does this -
> > vesa/uvesa. For these it is not possible to change the resolution from
> > fbdev, it just provides some framebuffer on top of which fb
> > applications or fbcons run.
> 
> Only because that is the only way to do it. The other options was to have 
> x86emul in the kernel. That was not going to happen.
>  
> > I guess equivalent of xrandr would be what people would want but the
> > current fbdev capabilities are far from that.
> > Since KMS provides these capabilities already I would think adding a
> > tool that manipulates KMS directly (kmset?) is the simplest way.
> 
> Still would have to deal with the issue of keeping the graphical console 
> in sync with the changes.
>  
> > There are other drivers that support multihead already (matroxfb, any
> > other?) and have their own driver-specific inteface.
> 
> Each crtc is treated as a seperate fbdev device. I don't recall any 
> special ioctls. Maybe for mirroring which was never standardized.

matroxfb does have a bunch of custom ioctls to change the crtc<->output
mapping. omapfb is another multihead fb driver and it's more complex
than matroxfb. Trying to make it perform various tricks through the
fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs)
is something I've been doing but I would not recommend it for anyone
who has the option of using a better API.

I don't think the CRTC=fb_info makes much sense if the main use
case is fbcon. fbcon will use a single fb device and so you can't see
the console on multiple heads anyway which makes the whole thing
somewhat pointless. And if you're trying to do something more complex
you will be a lot better off bypassing fbdev altogether.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michal Suchanek]

On 10 March 2010 22:04, Ville Syrjälä <syrjala@sci.fi> wrote:
> On Wed, Mar 10, 2010 at 06:11:29PM +0000, James Simmons wrote:
>>
>> > I don't think so. There is another driver which does this -
>> > vesa/uvesa. For these it is not possible to change the resolution from
>> > fbdev, it just provides some framebuffer on top of which fb
>> > applications or fbcons run.
>>
>> Only because that is the only way to do it. The other options was to have
>> x86emul in the kernel. That was not going to happen.
>>
>> > I guess equivalent of xrandr would be what people would want but the
>> > current fbdev capabilities are far from that.
>> > Since KMS provides these capabilities already I would think adding a
>> > tool that manipulates KMS directly (kmset?) is the simplest way.
>>
>> Still would have to deal with the issue of keeping the graphical console
>> in sync with the changes.
>>
>> > There are other drivers that support multihead already (matroxfb, any
>> > other?) and have their own driver-specific inteface.
>>
>> Each crtc is treated as a seperate fbdev device. I don't recall any
>> special ioctls. Maybe for mirroring which was never standardized.
>
> matroxfb does have a bunch of custom ioctls to change the crtc<->output
> mapping. omapfb is another multihead fb driver and it's more complex
> than matroxfb. Trying to make it perform various tricks through the
> fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs)
> is something I've been doing but I would not recommend it for anyone
> who has the option of using a better API.
>
> I don't think the CRTCû_info makes much sense if the main use
> case is fbcon. fbcon will use a single fb device and so you can't see
> the console on multiple heads anyway which makes the whole thing
> somewhat pointless. And if you're trying to do something more complex
> you will be a lot better off bypassing fbdev altogether.
>

I guess it's also possible that somebody would want the fbdev/fbcons
cover multiple screens. This is not particularly useful with fbcons
(although curses WMs exist) but might be somewhat useful for graphical
fbdev applications.

Multiple views of the kernel virtual consoles on different heads might
be nice toy but it's probably too hard to be worth trying. And there
are always applications like jfbterm which could be perhaps slightly
adapted to use one of the other devices instead of a vc.

Thanks

Michal

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

[Michal Suchanek]

On 10 March 2010 22:04, Ville Syrjälä <syrjala@sci.fi> wrote:
> On Wed, Mar 10, 2010 at 06:11:29PM +0000, James Simmons wrote:
>>
>> > I don't think so. There is another driver which does this -
>> > vesa/uvesa. For these it is not possible to change the resolution from
>> > fbdev, it just provides some framebuffer on top of which fb
>> > applications or fbcons run.
>>
>> Only because that is the only way to do it. The other options was to have
>> x86emul in the kernel. That was not going to happen.
>>
>> > I guess equivalent of xrandr would be what people would want but the
>> > current fbdev capabilities are far from that.
>> > Since KMS provides these capabilities already I would think adding a
>> > tool that manipulates KMS directly (kmset?) is the simplest way.
>>
>> Still would have to deal with the issue of keeping the graphical console
>> in sync with the changes.
>>
>> > There are other drivers that support multihead already (matroxfb, any
>> > other?) and have their own driver-specific inteface.
>>
>> Each crtc is treated as a seperate fbdev device. I don't recall any
>> special ioctls. Maybe for mirroring which was never standardized.
>
> matroxfb does have a bunch of custom ioctls to change the crtc<->output
> mapping. omapfb is another multihead fb driver and it's more complex
> than matroxfb. Trying to make it perform various tricks through the
> fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs)
> is something I've been doing but I would not recommend it for anyone
> who has the option of using a better API.
>
> I don't think the CRTC=fb_info makes much sense if the main use
> case is fbcon. fbcon will use a single fb device and so you can't see
> the console on multiple heads anyway which makes the whole thing
> somewhat pointless. And if you're trying to do something more complex
> you will be a lot better off bypassing fbdev altogether.
>

I guess it's also possible that somebody would want the fbdev/fbcons
cover multiple screens. This is not particularly useful with fbcons
(although curses WMs exist) but might be somewhat useful for graphical
fbdev applications.

Multiple views of the kernel virtual consoles on different heads might
be nice toy but it's probably too hard to be worth trying. And there
are always applications like jfbterm which could be perhaps slightly
adapted to use one of the other devices instead of a vc.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[James Simmons]

> > I don't think the CRTCû_info makes much sense if the main use
> > case is fbcon. fbcon will use a single fb device and so you can't see
> > the console on multiple heads anyway which makes the whole thing
> > somewhat pointless. And if you're trying to do something more complex
> > you will be a lot better off bypassing fbdev altogether.
> >
> 
> I guess it's also possible that somebody would want the fbdev/fbcons
> cover multiple screens. This is not particularly useful with fbcons
> (although curses WMs exist) but might be somewhat useful for graphical
> fbdev applications.

I really can't see fbcon need that.
 
> Multiple views of the kernel virtual consoles on different heads might
> be nice toy but it's probably too hard to be worth trying. And there
> are always applications like jfbterm which could be perhaps slightly
> adapted to use one of the other devices instead of a vc.

It already exist. I guess it is one of those best kept secrets.

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

[James Simmons]

> > I don't think the CRTC=fb_info makes much sense if the main use
> > case is fbcon. fbcon will use a single fb device and so you can't see
> > the console on multiple heads anyway which makes the whole thing
> > somewhat pointless. And if you're trying to do something more complex
> > you will be a lot better off bypassing fbdev altogether.
> >
> 
> I guess it's also possible that somebody would want the fbdev/fbcons
> cover multiple screens. This is not particularly useful with fbcons
> (although curses WMs exist) but might be somewhat useful for graphical
> fbdev applications.

I really can't see fbcon need that.
 
> Multiple views of the kernel virtual consoles on different heads might
> be nice toy but it's probably too hard to be worth trying. And there
> are always applications like jfbterm which could be perhaps slightly
> adapted to use one of the other devices instead of a vc.

It already exist. I guess it is one of those best kept secrets.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[James Simmons]

> > > There are other drivers that support multihead already (matroxfb, any
> > > other?) and have their own driver-specific inteface.
> > 
> > Each crtc is treated as a seperate fbdev device. I don't recall any 
> > special ioctls. Maybe for mirroring which was never standardized.
> 
> matroxfb does have a bunch of custom ioctls to change the crtc<->output
> mapping. 

Yes the mapping issue were never address.

> I don't think the CRTCû_info makes much sense if the main use
> case is fbcon.

Actually that is what I had in mind when I reworked the fbdev api. Plus 
with the linux console project I got multiple VTs working at the same 
time.

> fbcon will use a single fb device and so you can't see
> the console on multiple heads anyway which makes the whole thing
> somewhat pointless. And if you're trying to do something more complex
> you will be a lot better off bypassing fbdev altogether.

Not true. You can map different displays to different vcs. Give con2fb a 
try some time :-) Now there is the issue of more than one keyboard being 
mapped at a time. BTW I did getting multipe VT working at the same 
time working in the past. It requires some cleanup on the console layer.

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

[James Simmons]

> > > There are other drivers that support multihead already (matroxfb, any
> > > other?) and have their own driver-specific inteface.
> > 
> > Each crtc is treated as a seperate fbdev device. I don't recall any 
> > special ioctls. Maybe for mirroring which was never standardized.
> 
> matroxfb does have a bunch of custom ioctls to change the crtc<->output
> mapping. 

Yes the mapping issue were never address.

> I don't think the CRTC=fb_info makes much sense if the main use
> case is fbcon.

Actually that is what I had in mind when I reworked the fbdev api. Plus 
with the linux console project I got multiple VTs working at the same 
time.

> fbcon will use a single fb device and so you can't see
> the console on multiple heads anyway which makes the whole thing
> somewhat pointless. And if you're trying to do something more complex
> you will be a lot better off bypassing fbdev altogether.

Not true. You can map different displays to different vcs. Give con2fb a 
try some time :-) Now there is the issue of more than one keyboard being 
mapped at a time. BTW I did getting multipe VT working at the same 
time working in the past. It requires some cleanup on the console layer.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Ville Syrjälä]

On Thu, Mar 11, 2010 at 02:22:14AM +0000, James Simmons wrote:
> 
> > > > There are other drivers that support multihead already (matroxfb, any
> > > > other?) and have their own driver-specific inteface.
> > > 
> > > Each crtc is treated as a seperate fbdev device. I don't recall any 
> > > special ioctls. Maybe for mirroring which was never standardized.
> > 
> > matroxfb does have a bunch of custom ioctls to change the crtc<->output
> > mapping. 
> 
> Yes the mapping issue were never address.
> 
> > I don't think the CRTCû_info makes much sense if the main use
> > case is fbcon.
> 
> Actually that is what I had in mind when I reworked the fbdev api. Plus 
> with the linux console project I got multiple VTs working at the same 
> time.
> 
> > fbcon will use a single fb device and so you can't see
> > the console on multiple heads anyway which makes the whole thing
> > somewhat pointless. And if you're trying to do something more complex
> > you will be a lot better off bypassing fbdev altogether.
> 
> Not true. You can map different displays to different vcs. Give con2fb a 
> try some time :-)

I know about it but only one VT can be active at any given time.

> Now there is the issue of more than one keyboard being 
> mapped at a time. BTW I did getting multipe VT working at the same 
> time working in the past. It requires some cleanup on the console layer.

Well if you think that cleanup is possible and worth the effort then it
might make sense. The crtc<->output mapping is still unresolved though
and it depends on hardware which combinations are supported. If for
example the hardware can't drive multiple outputs with the same CRTC
or if the outputs require totally different timings then you can't
clone the same VT to multiple outputs.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

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

[Ville Syrjälä]

On Thu, Mar 11, 2010 at 02:22:14AM +0000, James Simmons wrote:
> 
> > > > There are other drivers that support multihead already (matroxfb, any
> > > > other?) and have their own driver-specific inteface.
> > > 
> > > Each crtc is treated as a seperate fbdev device. I don't recall any 
> > > special ioctls. Maybe for mirroring which was never standardized.
> > 
> > matroxfb does have a bunch of custom ioctls to change the crtc<->output
> > mapping. 
> 
> Yes the mapping issue were never address.
> 
> > I don't think the CRTC=fb_info makes much sense if the main use
> > case is fbcon.
> 
> Actually that is what I had in mind when I reworked the fbdev api. Plus 
> with the linux console project I got multiple VTs working at the same 
> time.
> 
> > fbcon will use a single fb device and so you can't see
> > the console on multiple heads anyway which makes the whole thing
> > somewhat pointless. And if you're trying to do something more complex
> > you will be a lot better off bypassing fbdev altogether.
> 
> Not true. You can map different displays to different vcs. Give con2fb a 
> try some time :-)

I know about it but only one VT can be active at any given time.

> Now there is the issue of more than one keyboard being 
> mapped at a time. BTW I did getting multipe VT working at the same 
> time working in the past. It requires some cleanup on the console layer.

Well if you think that cleanup is possible and worth the effort then it
might make sense. The crtc<->output mapping is still unresolved though
and it depends on hardware which combinations are supported. If for
example the hardware can't drive multiple outputs with the same CRTC
or if the outputs require totally different timings then you can't
clone the same VT to multiple outputs.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[James Simmons]

> My main problem with calling the drm underneath the fbdev is it
> seems like a layering violation. Then again some of code in the kernel
> is also contributing to this violation. I'd really like to make fbdev more
> like an in-kernel version of what X driver have to do, and leave all the
> initial modepicking etc to the fbdev interface layer.
> 
> If we take  the layering as
> fbcon -> fbdev -> kms -> hw
> 
> I feel calling ioctls on the KMS layer from userspace to do stuff for
> fbcon or fbdev
> is wrong, and we should rather expose a more intelligent set of ioctls via the
> fbdev device node. This points at quite a bit of typing.

	I agree. We had the same issue with fbdev and fbcon. From the 
fbcon layer you can call stty to change the resolution. In that case the 
mode change came from fbcon to fbdev. Easy problem to handle. Well some 
people still wanted to be able to able to change their console resolution 
with fbset. Not only change the resolution on one VC (virtual consoel) but 
in some cases change the resolution on all the VCs mapped to that fbdev. 
Now some times the user wanted to change the resolution for say a game (using 
SDL for example) and then expected the fbcon resolution to be restored 
when they exited. In that case we wanted the resolution change not to be 
propagated up to the fbcon layer. The way the fbdev changes are propagated 
with a notifier chain. Now the issue of mirroring is another thing which 
was never settled on.
	Considering now the KMS layer is not so bad as it seems. The fbdev 
emulation layer already changes the drm mode (fbdev -> kms) plus in that
case you get the benefit of automatically sending a signal to the fbcon 
layer to keep it in sync. In the case of kms -> fbdev you need to update 
the fbdev state. This could be done pretty easily plus if done right would
update the fbcon state as well.

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

[James Simmons]

> My main problem with calling the drm underneath the fbdev is it
> seems like a layering violation. Then again some of code in the kernel
> is also contributing to this violation. I'd really like to make fbdev more
> like an in-kernel version of what X driver have to do, and leave all the
> initial modepicking etc to the fbdev interface layer.
> 
> If we take  the layering as
> fbcon -> fbdev -> kms -> hw
> 
> I feel calling ioctls on the KMS layer from userspace to do stuff for
> fbcon or fbdev
> is wrong, and we should rather expose a more intelligent set of ioctls via the
> fbdev device node. This points at quite a bit of typing.

	I agree. We had the same issue with fbdev and fbcon. From the 
fbcon layer you can call stty to change the resolution. In that case the 
mode change came from fbcon to fbdev. Easy problem to handle. Well some 
people still wanted to be able to able to change their console resolution 
with fbset. Not only change the resolution on one VC (virtual consoel) but 
in some cases change the resolution on all the VCs mapped to that fbdev. 
Now some times the user wanted to change the resolution for say a game (using 
SDL for example) and then expected the fbcon resolution to be restored 
when they exited. In that case we wanted the resolution change not to be 
propagated up to the fbcon layer. The way the fbdev changes are propagated 
with a notifier chain. Now the issue of mirroring is another thing which 
was never settled on.
	Considering now the KMS layer is not so bad as it seems. The fbdev 
emulation layer already changes the drm mode (fbdev -> kms) plus in that
case you get the benefit of automatically sending a signal to the fbcon 
layer to keep it in sync. In the case of kms -> fbdev you need to update 
the fbdev state. This could be done pretty easily plus if done right would
update the fbcon state as well.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[James Simmons]

> >> 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.
> >
> 
> I've only really got two answer for this:
> 
> (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.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[James Simmons]

> >> 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.
> >
> 
> I've only really got two answer for this:
> 
> (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.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Alex Deucher]

On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>> >
>>
>> I've only really got two answer for this:
>>
>> (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.

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.

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Alex Deucher]

On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>> >
>>
>> I've only really got two answer for this:
>>
>> (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.

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.

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Alex Deucher]

On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>>
>>> >> 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.
>>> >
>>>
>>> I've only really got two answer for this:
>>>
>>> (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.
>
> 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.

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Alex Deucher]

On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>>
>>> >> 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.
>>> >
>>>
>>> I've only really got two answer for this:
>>>
>>> (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.
>
> 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.

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

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

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: drm_fb_helper: Impossible to change video mode

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

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

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

[Michal Suchanek]

On 10 March 2010 19:47, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>

Ability to print the oops over X does not seem to be that bad idea.
Since with KMS the kernel finally knows what X is doing with the
graphics it should be able to print it. Note that it may be the only
way to see it in situations when the console dies in one way or
another.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Michal Suchanek]

On 10 March 2010 19:47, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>

Ability to print the oops over X does not seem to be that bad idea.
Since with KMS the kernel finally knows what X is doing with the
graphics it should be able to print it. Note that it may be the only
way to see it in situations when the console dies in one way or
another.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Alex Deucher]

On Wed, Mar 10, 2010 at 1:47 PM, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>

Right now we keep the console buffer pinned in vram and we switch to
it when there is an oops or when you switch VTs.

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Alex Deucher]

On Wed, Mar 10, 2010 at 1:47 PM, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>

Right now we keep the console buffer pinned in vram and we switch to
it when there is an oops or when you switch VTs.

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michel Dänzer]

On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote: 
> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
> >>
> >> 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.

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.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Michel Dänzer]

On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote: 
> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
> >>
> >> 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.

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.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Pauli Nieminen]

2010/3/11 Michel Dänzer <michel@daenzer.net>:
> On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
>> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>> >>
>> >> 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.
>
> 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.
>

+1

For me only way to capture oopses is netconsole. But I'm causing all
my oopses in radeon/ttm modules. That might prevent the system from
returning to framebuffer console.

Pinning framebuffer console is only for developers feature so it
should be non-default option. For users it is more important to have
all VRAM available when required and fully functional console if they
use it.
In case of kernel oops there should some different way to collect them
in users system. They should be stored in hard disk for easier
attaching to the bug report. Also oopses that are stored in hd can be
later uploaded automatically with kerneloops daemon.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Pauli Nieminen]

2010/3/11 Michel Dänzer <michel@daenzer.net>:
> On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
>> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>> >>
>> >> 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.
>
> 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.
>

+1

For me only way to capture oopses is netconsole. But I'm causing all
my oopses in radeon/ttm modules. That might prevent the system from
returning to framebuffer console.

Pinning framebuffer console is only for developers feature so it
should be non-default option. For users it is more important to have
all VRAM available when required and fully functional console if they
use it.
In case of kernel oops there should some different way to collect them
in users system. They should be stored in hard disk for easier
attaching to the bug report. Also oopses that are stored in hd can be
later uploaded automatically with kerneloops daemon.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Alex Deucher]

2010/3/11 Michel Dänzer <michel@daenzer.net>:
> On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
>> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>> >>
>> >> 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.
>
> 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!

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Alex Deucher]

2010/3/11 Michel Dänzer <michel@daenzer.net>:
> On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
>> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>> >>
>> >> 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.
>
> 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!

Alex

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 959 bytes --]


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

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: drm_fb_helper: Impossible to change video mode

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 937 bytes --]


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

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[Michal Suchanek]

On 11 March 2010 16:17, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Michal Suchanek]

On 11 March 2010 16:17, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3196 bytes --]


On Thu, 11 Mar 2010, Michal Suchanek wrote:

> On 11 March 2010 16:17, James Simmons <jsimmons@infradead.org> wrote:
> >
> >> >> 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 
api to another :-( From the code it appears GEM is the main userland interface
when using KMS. Some how TTM is also usable from userland but I never found a
clear example of how that is done. So to the average userland app writer it is
a mystery. As for hardware that has a static front buffer I can see how to 
use drm_maps or TTM but I don't see a easy way to map it to the GEM api. 
Also their exist ioctl for gem but it appears no one actually uses them 
but instead write their own :-( So you can see the confusion here. 
	Outside of what I described above the drm_framebuffer handling is 
a mess. From what I can see with the code you can only create a 
drm_framebuffer with the GEM api. With this case the two most important 
functions to provide are

dev->mode_config.funcs->fb_create(dev, file_priv, r)

and

fb->funcs->create_handle(fb, file_priv, &r->handle);

As you can see if the functions they depend on a handle and a drm_file. To 
make it possible to create a framebuffer internally using a common code we 
would remove those requirements. 
	This gets me to point of where to go from here. We have two choices.
The first being we could just make the drm_framebuffer code totally gem 
dependent thus we could cleanup the drivers code up by moving gem code 
there. The second option is to make the drm_framebuffer code agnostic to the gem 
layer. So I have been pondering on how to make the second option work. 
There is one thing that all these layers do share in common. That is they 
have some sort of drm_hash with a object lookup. Still pondering how that 
would be done.

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3131 bytes --]


On Thu, 11 Mar 2010, Michal Suchanek wrote:

> On 11 March 2010 16:17, James Simmons <jsimmons@infradead.org> wrote:
> >
> >> >> 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 
api to another :-( From the code it appears GEM is the main userland interface
when using KMS. Some how TTM is also usable from userland but I never found a
clear example of how that is done. So to the average userland app writer it is
a mystery. As for hardware that has a static front buffer I can see how to 
use drm_maps or TTM but I don't see a easy way to map it to the GEM api. 
Also their exist ioctl for gem but it appears no one actually uses them 
but instead write their own :-( So you can see the confusion here. 
	Outside of what I described above the drm_framebuffer handling is 
a mess. From what I can see with the code you can only create a 
drm_framebuffer with the GEM api. With this case the two most important 
functions to provide are

dev->mode_config.funcs->fb_create(dev, file_priv, r)

and

fb->funcs->create_handle(fb, file_priv, &r->handle);

As you can see if the functions they depend on a handle and a drm_file. To 
make it possible to create a framebuffer internally using a common code we 
would remove those requirements. 
	This gets me to point of where to go from here. We have two choices.
The first being we could just make the drm_framebuffer code totally gem 
dependent thus we could cleanup the drivers code up by moving gem code 
there. The second option is to make the drm_framebuffer code agnostic to the gem 
layer. So I have been pondering on how to make the second option work. 
There is one thing that all these layers do share in common. That is they 
have some sort of drm_hash with a object lookup. Still pondering how that 
would be done.

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Dave Airlie]

>> >
>> >> >> 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
> api to another :-( From the code it appears GEM is the main userland interface
> when using KMS. Some how TTM is also usable from userland but I never found a
> clear example of how that is done. So to the average userland app writer it is
> a mystery. As for hardware that has a static front buffer I can see how to
> use drm_maps or TTM but I don't see a easy way to map it to the GEM api.
> Also their exist ioctl for gem but it appears no one actually uses them
> but instead write their own :-( So you can see the confusion here.

Userspace buffer management interfaces are pre-driver, the only requirement
if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers
don't exist for the purposes of fb interaction, so drm_maps are ignorable from
that pov.

>        Outside of what I described above the drm_framebuffer handling is
> a mess. From what I can see with the code you can only create a
> drm_framebuffer with the GEM api. With this case the two most important
> functions to provide are

This isn't correct. You get a drm_file and a handle, the driver then uses
these to do whatever it wants to do. This means lookup a GEM object or
whatever but there is no reliance on GEM or any other memory manager
outside the driver. Again a handle a file priv are in no way GEM specific.

>
> dev->mode_config.funcs->fb_create(dev, file_priv, r)
>
> and
>
> fb->funcs->create_handle(fb, file_priv, &r->handle);
>
> As you can see if the functions they depend on a handle and a drm_file. To
> make it possible to create a framebuffer internally using a common code we
> would remove those requirements.

We already have an internal framebuffer creation for fbdev, there is
an fb_create
callback that does this, its not up to dynamic fbdev creation.

>        This gets me to point of where to go from here. We have two choices.
> The first being we could just make the drm_framebuffer code totally gem
> dependent thus we could cleanup the drivers code up by moving gem code
> there. The second option is to make the drm_framebuffer code agnostic to the gem
> layer. So I have been pondering on how to make the second option work.
> There is one thing that all these layers do share in common. That is they
> have some sort of drm_hash with a object lookup. Still pondering how that
> would be done.

I'm not sure either of these makes sense, can you clearly state the
goal and maybe
we can work out what you need.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Dave Airlie]

>> >
>> >> >> 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
> api to another :-( From the code it appears GEM is the main userland interface
> when using KMS. Some how TTM is also usable from userland but I never found a
> clear example of how that is done. So to the average userland app writer it is
> a mystery. As for hardware that has a static front buffer I can see how to
> use drm_maps or TTM but I don't see a easy way to map it to the GEM api.
> Also their exist ioctl for gem but it appears no one actually uses them
> but instead write their own :-( So you can see the confusion here.

Userspace buffer management interfaces are pre-driver, the only requirement
if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers
don't exist for the purposes of fb interaction, so drm_maps are ignorable from
that pov.

>        Outside of what I described above the drm_framebuffer handling is
> a mess. From what I can see with the code you can only create a
> drm_framebuffer with the GEM api. With this case the two most important
> functions to provide are

This isn't correct. You get a drm_file and a handle, the driver then uses
these to do whatever it wants to do. This means lookup a GEM object or
whatever but there is no reliance on GEM or any other memory manager
outside the driver. Again a handle a file priv are in no way GEM specific.

>
> dev->mode_config.funcs->fb_create(dev, file_priv, r)
>
> and
>
> fb->funcs->create_handle(fb, file_priv, &r->handle);
>
> As you can see if the functions they depend on a handle and a drm_file. To
> make it possible to create a framebuffer internally using a common code we
> would remove those requirements.

We already have an internal framebuffer creation for fbdev, there is
an fb_create
callback that does this, its not up to dynamic fbdev creation.

>        This gets me to point of where to go from here. We have two choices.
> The first being we could just make the drm_framebuffer code totally gem
> dependent thus we could cleanup the drivers code up by moving gem code
> there. The second option is to make the drm_framebuffer code agnostic to the gem
> layer. So I have been pondering on how to make the second option work.
> There is one thing that all these layers do share in common. That is they
> have some sort of drm_hash with a object lookup. Still pondering how that
> would be done.

I'm not sure either of these makes sense, can you clearly state the
goal and maybe
we can work out what you need.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3340 bytes --]


> >> 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
> > api to another :-( From the code it appears GEM is the main userland interface
> > when using KMS. Some how TTM is also usable from userland but I never found a
> > clear example of how that is done. So to the average userland app writer it is
> > a mystery. As for hardware that has a static front buffer I can see how to
> > use drm_maps or TTM but I don't see a easy way to map it to the GEM api.
> > Also their exist ioctl for gem but it appears no one actually uses them
> > but instead write their own :-( So you can see the confusion here.
> 
> Userspace buffer management interfaces are pre-driver, the only requirement
> if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers
> don't exist for the purposes of fb interaction, so drm_maps are ignorable from
> that pov.

 
> >        Outside of what I described above the drm_framebuffer handling is
> > a mess. From what I can see with the code you can only create a
> > drm_framebuffer with the GEM api. With this case the two most important
> > functions to provide are
> 
> This isn't correct. You get a drm_file and a handle, the driver then uses
> these to do whatever it wants to do. This means lookup a GEM object or
> whatever but there is no reliance on GEM or any other memory manager
> outside the driver. Again a handle a file priv are in no way GEM specific.

Searching the TTM code I couldn't find the handle code so easily. I see 
that the vmwgfx driver provides a example of using ttm.
 
> >        This gets me to point of where to go from here. We have two choices.
> > The first being we could just make the drm_framebuffer code totally gem
> > dependent thus we could cleanup the drivers code up by moving gem code
> > there. The second option is to make the drm_framebuffer code agnostic to the gem
> > layer. So I have been pondering on how to make the second option work.
> > There is one thing that all these layers do share in common. That is they
> > have some sort of drm_hash with a object lookup. Still pondering how that
> > would be done.
> 
> I'm not sure either of these makes sense, can you clearly state the
> goal and maybe we can work out what you need.

Sorry I should of stated what I was planing to do. I like to see drmfb 
have the ablitiy to change the resolution via fbset. To do that we need to 
be able to create and destory the framebuffer memory if the memory doesn't 
fit the size of the new resolution. Plus it gives us the bonus of being 
able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem 
is that the functions like fb_create are tied to a handle which is not 
present for the internal framebuffer used by fbdev. Sorry for the junk 
above. It just took me awhile to figure out the code. Their is steep 
learning curve. I have patches that should address this coming soon.


[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: drm_fb_helper: Impossible to change video mode

[James Simmons]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3281 bytes --]


> >> 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
> > api to another :-( From the code it appears GEM is the main userland interface
> > when using KMS. Some how TTM is also usable from userland but I never found a
> > clear example of how that is done. So to the average userland app writer it is
> > a mystery. As for hardware that has a static front buffer I can see how to
> > use drm_maps or TTM but I don't see a easy way to map it to the GEM api.
> > Also their exist ioctl for gem but it appears no one actually uses them
> > but instead write their own :-( So you can see the confusion here.
> 
> Userspace buffer management interfaces are pre-driver, the only requirement
> if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers
> don't exist for the purposes of fb interaction, so drm_maps are ignorable from
> that pov.

 
> >        Outside of what I described above the drm_framebuffer handling is
> > a mess. From what I can see with the code you can only create a
> > drm_framebuffer with the GEM api. With this case the two most important
> > functions to provide are
> 
> This isn't correct. You get a drm_file and a handle, the driver then uses
> these to do whatever it wants to do. This means lookup a GEM object or
> whatever but there is no reliance on GEM or any other memory manager
> outside the driver. Again a handle a file priv are in no way GEM specific.

Searching the TTM code I couldn't find the handle code so easily. I see 
that the vmwgfx driver provides a example of using ttm.
 
> >        This gets me to point of where to go from here. We have two choices.
> > The first being we could just make the drm_framebuffer code totally gem
> > dependent thus we could cleanup the drivers code up by moving gem code
> > there. The second option is to make the drm_framebuffer code agnostic to the gem
> > layer. So I have been pondering on how to make the second option work.
> > There is one thing that all these layers do share in common. That is they
> > have some sort of drm_hash with a object lookup. Still pondering how that
> > would be done.
> 
> I'm not sure either of these makes sense, can you clearly state the
> goal and maybe we can work out what you need.

Sorry I should of stated what I was planing to do. I like to see drmfb 
have the ablitiy to change the resolution via fbset. To do that we need to 
be able to create and destory the framebuffer memory if the memory doesn't 
fit the size of the new resolution. Plus it gives us the bonus of being 
able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem 
is that the functions like fb_create are tied to a handle which is not 
present for the internal framebuffer used by fbdev. Sorry for the junk 
above. It just took me awhile to figure out the code. Their is steep 
learning curve. I have patches that should address this coming soon.


[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[Dave Airlie]

>
> Searching the TTM code I couldn't find the handle code so easily. I see
> that the vmwgfx driver provides a example of using ttm.

So handles are purely a userspace interface, in-kernel we don't use handles
for buffer management, the vmwgfx TTM interface has
vmw_user_surface_lookup_handle
to do the bo lookups.

>
>> >        This gets me to point of where to go from here. We have two choices.
>> > The first being we could just make the drm_framebuffer code totally gem
>> > dependent thus we could cleanup the drivers code up by moving gem code
>> > there. The second option is to make the drm_framebuffer code agnostic to the gem
>> > layer. So I have been pondering on how to make the second option work.
>> > There is one thing that all these layers do share in common. That is they
>> > have some sort of drm_hash with a object lookup. Still pondering how that
>> > would be done.
>>
>> I'm not sure either of these makes sense, can you clearly state the
>> goal and maybe we can work out what you need.
>
> Sorry I should of stated what I was planing to do. I like to see drmfb
> have the ablitiy to change the resolution via fbset. To do that we need to
> be able to create and destory the framebuffer memory if the memory doesn't
> fit the size of the new resolution. Plus it gives us the bonus of being
> able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem
> is that the functions like fb_create are tied to a handle which is not
> present for the internal framebuffer used by fbdev. Sorry for the junk
> above. It just took me awhile to figure out the code. Their is steep
> learning curve. I have patches that should address this coming soon.

Okay first up, there are two sets of codepaths, please ignore vmwgfx
for now, its
_fb implementation is not yet using the drm_fb_helper.c code and it needs to be
converted if possible. Originally all the drivers had their own fb
code, but its was
mostly pointless, the helper allows for drivers to optionally use the
shared code,
ideally we'd like all drivers to use that code so we get consistent
operation across
drivers, so user experience isn't driver dependent unless unavoidable.

The big issue we have with resizing the buffer is userspace mmaps of the fbdev
device, and invalidation.
Previous thread of unresolvedness is here.
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html

If you look at the current fb code, when we get a hotplug event in
theory, we try and
reuse the current framebuffer.

I suppose initially it would be worth trying the resize downwards and keep the
current fbdev, but the whole mmap area was the cause of most of the problems
and it seemed like a real pain to fix.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Dave Airlie]

>
> Searching the TTM code I couldn't find the handle code so easily. I see
> that the vmwgfx driver provides a example of using ttm.

So handles are purely a userspace interface, in-kernel we don't use handles
for buffer management, the vmwgfx TTM interface has
vmw_user_surface_lookup_handle
to do the bo lookups.

>
>> >        This gets me to point of where to go from here. We have two choices.
>> > The first being we could just make the drm_framebuffer code totally gem
>> > dependent thus we could cleanup the drivers code up by moving gem code
>> > there. The second option is to make the drm_framebuffer code agnostic to the gem
>> > layer. So I have been pondering on how to make the second option work.
>> > There is one thing that all these layers do share in common. That is they
>> > have some sort of drm_hash with a object lookup. Still pondering how that
>> > would be done.
>>
>> I'm not sure either of these makes sense, can you clearly state the
>> goal and maybe we can work out what you need.
>
> Sorry I should of stated what I was planing to do. I like to see drmfb
> have the ablitiy to change the resolution via fbset. To do that we need to
> be able to create and destory the framebuffer memory if the memory doesn't
> fit the size of the new resolution. Plus it gives us the bonus of being
> able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem
> is that the functions like fb_create are tied to a handle which is not
> present for the internal framebuffer used by fbdev. Sorry for the junk
> above. It just took me awhile to figure out the code. Their is steep
> learning curve. I have patches that should address this coming soon.

Okay first up, there are two sets of codepaths, please ignore vmwgfx
for now, its
_fb implementation is not yet using the drm_fb_helper.c code and it needs to be
converted if possible. Originally all the drivers had their own fb
code, but its was
mostly pointless, the helper allows for drivers to optionally use the
shared code,
ideally we'd like all drivers to use that code so we get consistent
operation across
drivers, so user experience isn't driver dependent unless unavoidable.

The big issue we have with resizing the buffer is userspace mmaps of the fbdev
device, and invalidation.
Previous thread of unresolvedness is here.
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html

If you look at the current fb code, when we get a hotplug event in
theory, we try and
reuse the current framebuffer.

I suppose initially it would be worth trying the resize downwards and keep the
current fbdev, but the whole mmap area was the cause of most of the problems
and it seemed like a real pain to fix.

Dave.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michel Dänzer]

On Sun, 2010-03-14 at 07:01 +1000, Dave Airlie wrote: 
> 
> The big issue we have with resizing the buffer is userspace mmaps of the fbdev
> device, and invalidation.
> Previous thread of unresolvedness is here.
> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html

Actually AFAIR (and reading through it again seems to confirm this)
userspace mappings should be fully handled by the last patch series I
posted back then[0]. The problem was that the struct fb_ops hooks may be
called by the kernel from pretty much any context, and neither I nor
Thomas was sure how to handle the TTM locking given that. Maybe James
has ideas for this given his better familiarity with fbdev internals.


[0] Though that was really only about making it possible to unpin the
fbcon BO while it isn't being displayed, resizing it might involve other
issues I'm not aware of.

-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[Michel Dänzer]

On Sun, 2010-03-14 at 07:01 +1000, Dave Airlie wrote: 
> 
> The big issue we have with resizing the buffer is userspace mmaps of the fbdev
> device, and invalidation.
> Previous thread of unresolvedness is here.
> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html

Actually AFAIR (and reading through it again seems to confirm this)
userspace mappings should be fully handled by the last patch series I
posted back then[0]. The problem was that the struct fb_ops hooks may be
called by the kernel from pretty much any context, and neither I nor
Thomas was sure how to handle the TTM locking given that. Maybe James
has ideas for this given his better familiarity with fbdev internals.


[0] Though that was really only about making it possible to unpin the
fbcon BO while it isn't being displayed, resizing it might involve other
issues I'm not aware of.

-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[James Simmons]

> > The big issue we have with resizing the buffer is userspace mmaps of the fbdev
> > device, and invalidation.
> > Previous thread of unresolvedness is here.
> > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html
> 
> Actually AFAIR (and reading through it again seems to confirm this)
> userspace mappings should be fully handled by the last patch series I
> posted back then[0]. The problem was that the struct fb_ops hooks may be
> called by the kernel from pretty much any context, and neither I nor
> Thomas was sure how to handle the TTM locking given that. Maybe James
> has ideas for this given his better familiarity with fbdev internals.

The fb_ops can only be called from fbcon or the fbdev userland interface. 
The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
with the DRM backend we have the advantage of creating a mapping seperate 
from the console mapping. A fb_open/fb_close could be used to cleaning up 
the userland mmap as well as handle the console pinning. We can supply 
your own fb_mmap hook.

> [0] Though that was really only about making it possible to unpin the
> fbcon BO while it isn't being displayed, resizing it might involve other
> issues I'm not aware of.

Yeap, but both problems are related. Kill two birds with one stone.

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

[James Simmons]

> > The big issue we have with resizing the buffer is userspace mmaps of the fbdev
> > device, and invalidation.
> > Previous thread of unresolvedness is here.
> > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html
> 
> Actually AFAIR (and reading through it again seems to confirm this)
> userspace mappings should be fully handled by the last patch series I
> posted back then[0]. The problem was that the struct fb_ops hooks may be
> called by the kernel from pretty much any context, and neither I nor
> Thomas was sure how to handle the TTM locking given that. Maybe James
> has ideas for this given his better familiarity with fbdev internals.

The fb_ops can only be called from fbcon or the fbdev userland interface. 
The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
with the DRM backend we have the advantage of creating a mapping seperate 
from the console mapping. A fb_open/fb_close could be used to cleaning up 
the userland mmap as well as handle the console pinning. We can supply 
your own fb_mmap hook.

> [0] Though that was really only about making it possible to unpin the
> fbcon BO while it isn't being displayed, resizing it might involve other
> issues I'm not aware of.

Yeap, but both problems are related. Kill two birds with one stone.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michel Dänzer]

On Mon, 2010-03-15 at 18:38 +0000, James Simmons wrote: 
> > > The big issue we have with resizing the buffer is userspace mmaps of the fbdev
> > > device, and invalidation.
> > > Previous thread of unresolvedness is here.
> > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html
> > 
> > Actually AFAIR (and reading through it again seems to confirm this)
> > userspace mappings should be fully handled by the last patch series I
> > posted back then[0]. The problem was that the struct fb_ops hooks may be
> > called by the kernel from pretty much any context, and neither I nor
> > Thomas was sure how to handle the TTM locking given that. Maybe James
> > has ideas for this given his better familiarity with fbdev internals.
> 
> The fb_ops can only be called from fbcon or the fbdev userland interface. 
> The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> with the DRM backend we have the advantage of creating a mapping seperate 
> from the console mapping. A fb_open/fb_close could be used to cleaning up 
> the userland mmap as well as handle the console pinning. We can supply 
> your own fb_mmap hook.

Again, the issue is not userspace but that fb_ops hooks can be called
from interrupt context etc.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

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

[Michel Dänzer]

On Mon, 2010-03-15 at 18:38 +0000, James Simmons wrote: 
> > > The big issue we have with resizing the buffer is userspace mmaps of the fbdev
> > > device, and invalidation.
> > > Previous thread of unresolvedness is here.
> > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html
> > 
> > Actually AFAIR (and reading through it again seems to confirm this)
> > userspace mappings should be fully handled by the last patch series I
> > posted back then[0]. The problem was that the struct fb_ops hooks may be
> > called by the kernel from pretty much any context, and neither I nor
> > Thomas was sure how to handle the TTM locking given that. Maybe James
> > has ideas for this given his better familiarity with fbdev internals.
> 
> The fb_ops can only be called from fbcon or the fbdev userland interface. 
> The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> with the DRM backend we have the advantage of creating a mapping seperate 
> from the console mapping. A fb_open/fb_close could be used to cleaning up 
> the userland mmap as well as handle the console pinning. We can supply 
> your own fb_mmap hook.

Again, the issue is not userspace but that fb_ops hooks can be called
from interrupt context etc.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[James Simmons]

> > The fb_ops can only be called from fbcon or the fbdev userland interface. 
> > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> > with the DRM backend we have the advantage of creating a mapping seperate 
> > from the console mapping. A fb_open/fb_close could be used to cleaning up 
> > the userland mmap as well as handle the console pinning. We can supply 
> > your own fb_mmap hook.
> 
> Again, the issue is not userspace but that fb_ops hooks can be called
> from interrupt context etc.

This should not happen. The VT layer is protected from calling in the 
interrupt context. TNor does fbcon call any fb_ops methods from a irq.
I have to look at the fbdev drivers but to my knowledge none touch any 
memory while in a context. Have you seen this happen before? Please let me 
know do I can fix it right a way.

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

[James Simmons]

> > The fb_ops can only be called from fbcon or the fbdev userland interface. 
> > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> > with the DRM backend we have the advantage of creating a mapping seperate 
> > from the console mapping. A fb_open/fb_close could be used to cleaning up 
> > the userland mmap as well as handle the console pinning. We can supply 
> > your own fb_mmap hook.
> 
> Again, the issue is not userspace but that fb_ops hooks can be called
> from interrupt context etc.

This should not happen. The VT layer is protected from calling in the 
interrupt context. TNor does fbcon call any fb_ops methods from a irq.
I have to look at the fbdev drivers but to my knowledge none touch any 
memory while in a context. Have you seen this happen before? Please let me 
know do I can fix it right a way.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michel Dänzer]

On Tue, 2010-03-16 at 13:56 +0000, James Simmons wrote: 
> > > The fb_ops can only be called from fbcon or the fbdev userland interface. 
> > > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> > > with the DRM backend we have the advantage of creating a mapping seperate 
> > > from the console mapping. A fb_open/fb_close could be used to cleaning up 
> > > the userland mmap as well as handle the console pinning. We can supply 
> > > your own fb_mmap hook.
> > 
> > Again, the issue is not userspace but that fb_ops hooks can be called
> > from interrupt context etc.
> 
> This should not happen. The VT layer is protected from calling in the 
> interrupt context. TNor does fbcon call any fb_ops methods from a irq.

E.g. printk?


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

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

[Michel Dänzer]

On Tue, 2010-03-16 at 13:56 +0000, James Simmons wrote: 
> > > The fb_ops can only be called from fbcon or the fbdev userland interface. 
> > > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> > > with the DRM backend we have the advantage of creating a mapping seperate 
> > > from the console mapping. A fb_open/fb_close could be used to cleaning up 
> > > the userland mmap as well as handle the console pinning. We can supply 
> > > your own fb_mmap hook.
> > 
> > Again, the issue is not userspace but that fb_ops hooks can be called
> > from interrupt context etc.
> 
> This should not happen. The VT layer is protected from calling in the 
> interrupt context. TNor does fbcon call any fb_ops methods from a irq.

E.g. printk?


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

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

[James Simmons]

> > > > The fb_ops can only be called from fbcon or the fbdev userland interface. 
> > > > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> > > > with the DRM backend we have the advantage of creating a mapping seperate 
> > > > from the console mapping. A fb_open/fb_close could be used to cleaning up 
> > > > the userland mmap as well as handle the console pinning. We can supply 
> > > > your own fb_mmap hook.
> > > 
> > > Again, the issue is not userspace but that fb_ops hooks can be called
> > > from interrupt context etc.
> > 
> > This should not happen. The VT layer is protected from calling in the 
> > interrupt context. TNor does fbcon call any fb_ops methods from a irq.
> 
> E.g. printk?

Sorry I have been sick. This is true when you are in KD_TEXT mode and using fbcon. 
Now while working on a graphical console yes you can have other hardware devices do
a printk which can alter the state of of your graphics card. As for debugging a 
graphics driver you have to be very careful with your printks. Usually in that case
I use two graphics cards in my system and map one to fbcon and test the other
graphcis cards driver.

P.S
	The fbdev api is such that it doesn't always require a permanent framebuffer
mapping. This was done for the case of graphical hardware that lacks a directly 
accessable framebuffer. If you have accelerated fillrect,copyarea,and imageblit then 
you don't even the mapping except in the case of someone calling mmap on /dev/fbX.
I noticed the nouveau drivers has a accelerated fbcon :-)

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

[James Simmons]

> > > > The fb_ops can only be called from fbcon or the fbdev userland interface. 
> > > > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now 
> > > > with the DRM backend we have the advantage of creating a mapping seperate 
> > > > from the console mapping. A fb_open/fb_close could be used to cleaning up 
> > > > the userland mmap as well as handle the console pinning. We can supply 
> > > > your own fb_mmap hook.
> > > 
> > > Again, the issue is not userspace but that fb_ops hooks can be called
> > > from interrupt context etc.
> > 
> > This should not happen. The VT layer is protected from calling in the 
> > interrupt context. TNor does fbcon call any fb_ops methods from a irq.
> 
> E.g. printk?

Sorry I have been sick. This is true when you are in KD_TEXT mode and using fbcon. 
Now while working on a graphical console yes you can have other hardware devices do
a printk which can alter the state of of your graphics card. As for debugging a 
graphics driver you have to be very careful with your printks. Usually in that case
I use two graphics cards in my system and map one to fbcon and test the other
graphcis cards driver.

P.S
	The fbdev api is such that it doesn't always require a permanent framebuffer
mapping. This was done for the case of graphical hardware that lacks a directly 
accessable framebuffer. If you have accelerated fillrect,copyarea,and imageblit then 
you don't even the mapping except in the case of someone calling mmap on /dev/fbX.
I noticed the nouveau drivers has a accelerated fbcon :-)

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[James Simmons]

> > Searching the TTM code I couldn't find the handle code so easily. I see
> > that the vmwgfx driver provides a example of using ttm.
> 
> So handles are purely a userspace interface, in-kernel we don't use handles
> for buffer management, the vmwgfx TTM interface has vmw_user_surface_lookup_handle
> to do the bo lookups.

Yeap, some how userland has to tell which buffer is which. I also noticed 
their is a ttm_base_object_lookup which does the same thing :-) 


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: drm_fb_helper: Impossible to change video mode

[James Simmons]

> > Searching the TTM code I couldn't find the handle code so easily. I see
> > that the vmwgfx driver provides a example of using ttm.
> 
> So handles are purely a userspace interface, in-kernel we don't use handles
> for buffer management, the vmwgfx TTM interface has vmw_user_surface_lookup_handle
> to do the bo lookups.

Yeap, some how userland has to tell which buffer is which. I also noticed 
their is a ttm_base_object_lookup which does the same thing :-) 


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

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

[Michal Suchanek]

On 10 March 2010 18:42, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>> >
>>
>> I've only really got two answer for this:
>>
>> (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.
>

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.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

[Michal Suchanek]

On 10 March 2010 18:42, James Simmons <jsimmons@infradead.org> wrote:
>
>> >> 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.
>> >
>>
>> I've only really got two answer for this:
>>
>> (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.
>

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.

Thanks

Michal

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

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

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

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: drm_fb_helper: Impossible to change video mode

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

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

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

[James Simmons]

> On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:
> 
> > 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?

Yes it could work. No it doesn't work.
 
> >
> > 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).
> >
> 
> I would say it's time to support multihead with fbset properly.
> 
> That is people would need new fbset which sees both (all) heads, and
> fbset can then choose the head itself (and people can make it do
> something different when they don't like the default). It should also
> support setting up rotation on each head.
> 
> For old fbset setting something visible is probably good enough.
> 
> 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.

	Before we go there you have to reflect on what the original reason was to 
have a framebuffer layer. The point to have a VT console terminal on 
platforms that lacked hardware that supported native text mode hardware. 
In other words had no vga text mode. A VT terminal is just a keyboard and 
a display. In fact in the old days you had to write framebuffer console 
drivers with things like con_putcs, con_write. Then the api was changed to 
make driver writing simple. The struct fb_info represented your graphics 
card.
	Of course at that time we also had hardware that supported more 
than one crtc which made things more complex. This was reflected in the 
new api. Struct fb_info was moved in the direction to represent the 
display. Remember the terminal only really cares about the display. Inside 
struct fb_info we have a void *par that was a pointer to some structure 
that represented the graphics card itself. So in the case of multi-head 
systems you could have two struct fb_info and one shared *par. That way if 
you wanted to changed the resolution on one screen the check_var function 
could using the *par to test if the hardware could support both 
resolutions at the same time. 
	Note also there is exist a sysfs that allows you to migrate your 
second fbdev devices to a new terminal. Also problems exist in the upper 
console layers that prohibit true multi-desktop systems.

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

[James Simmons]

> On 21 November 2009 05:27, Dave Airlie <airlied@gmail.com> wrote:
> 
> > 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?

Yes it could work. No it doesn't work.
 
> >
> > 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).
> >
> 
> I would say it's time to support multihead with fbset properly.
> 
> That is people would need new fbset which sees both (all) heads, and
> fbset can then choose the head itself (and people can make it do
> something different when they don't like the default). It should also
> support setting up rotation on each head.
> 
> For old fbset setting something visible is probably good enough.
> 
> 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.

	Before we go there you have to reflect on what the original reason was to 
have a framebuffer layer. The point to have a VT console terminal on 
platforms that lacked hardware that supported native text mode hardware. 
In other words had no vga text mode. A VT terminal is just a keyboard and 
a display. In fact in the old days you had to write framebuffer console 
drivers with things like con_putcs, con_write. Then the api was changed to 
make driver writing simple. The struct fb_info represented your graphics 
card.
	Of course at that time we also had hardware that supported more 
than one crtc which made things more complex. This was reflected in the 
new api. Struct fb_info was moved in the direction to represent the 
display. Remember the terminal only really cares about the display. Inside 
struct fb_info we have a void *par that was a pointer to some structure 
that represented the graphics card itself. So in the case of multi-head 
systems you could have two struct fb_info and one shared *par. That way if 
you wanted to changed the resolution on one screen the check_var function 
could using the *par to test if the hardware could support both 
resolutions at the same time. 
	Note also there is exist a sysfs that allows you to migrate your 
second fbdev devices to a new terminal. Also problems exist in the upper 
console layers that prohibit true multi-desktop systems.


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--