[PATCH 0/7] Detaching fbcon

[PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

One of the limitations of the framebuffer console system is its inablity to
unload or detach itself from the console layer.  And once it loads, it also
locks in framebuffer drivers preventing their unload. Although the con2fbmap
utility does provide a means to unload individual drivers, it requires that at
least one framebuffer driver is loaded for use by fbcon.

With this change, it is possible to detach fbcon from the console layer. If it
is detached, it will reattach the boot console driver (which is permanently
loaded) back to the console layer so the system can continue to work.  As a
consequence, fbcon will also decrement its reference count of individual
framebuffer drivers, allowing all of these drivers to be unloaded even if
fbcon is still loaded.

Unless you use drivers that restores the display to text mode (rivafb and
i810fb, for example), detaching fbcon does require assistance from userspace
tools (ie, vbetools) for text mode to be restored completely.  Without the
help of these tools, fbcon will leave the VGA console corrupted. The methods
that can be used will be described in Documentation/fb/fbcon.txt.

Because the vt layer also increments the module reference count for each
console driver, fbcon cannot be directly unloaded.  It must be detached first
prior to unload.

Similarly, fbcon can be reattached to the console layer without having to
reload the module.  A nice feature if fbcon is compiled statically.

Attaching and detaching fbcon is done via sysfs attributes. A class device
entry for fbcon is created in /sys/class/graphics. The two attributes that
controls this feature are detach and attach. Two other attributes that are
piggybacked under /sys/class/graphics/fb[n] that are fbcon-specific,
'con_rotate' and 'con_rotate_all' are moved to fbcon.  They are renamed as
'rotate' and 'rotate_all' respectively.

Overall, this feature is a great help for developers working in the
framebuffer or console layer.  There is not need to continually reboot the
kernel for every small change. It is also useful for regular users who wants
to choose between a graphical console or a text console without having to
reboot.

Example usage for x86:

/* start in text mode */
modprobe xxxfb
modprobe fbcon
/* graphical mode with fbcon using xxxfb */
echo 1 > /sys/class/graphics/fbcon/detach
/* back to text mode, will produce corrupt display unless vbetool is used */
rmmod xxxfb
modprobe yyyfb
/* back to graphical mode with fbcon using yyyfb */

Before trying out this feature, please read Documentation/fb/fbcon.txt.

Re: [PATCH 0/7] Detaching fbcon

[Jon Smirl]

On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Overall, this feature is a great help for developers working in the
> framebuffer or console layer.  There is not need to continually reboot the
> kernel for every small change. It is also useful for regular users who wants
> to choose between a graphical console or a text console without having to
> reboot.

Instead of the sysfs attribute, what about creating a new escape
sequence that you send to the console system to detach? Doing it that
way would make more sense from a stacking order. It just seems
backwards to me that you ask a lower layer to detach from the layer
above it. The escape sequence would also work for any console
implementation, not just fbcon.

If console detached this way and there was nothing to fallback to
(systems without VGAcon), it would know not to try and print anything
until something reattaches to it.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 0/7] Detaching fbcon

[Jon Smirl]

On 6/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > Overall, this feature is a great help for developers working in the
> > framebuffer or console layer.  There is not need to continually reboot the
> > kernel for every small change. It is also useful for regular users who wants
> > to choose between a graphical console or a text console without having to
> > reboot.
>
> Instead of the sysfs attribute, what about creating a new escape
> sequence that you send to the console system to detach? Doing it that
> way would make more sense from a stacking order. It just seems
> backwards to me that you ask a lower layer to detach from the layer
> above it. The escape sequence would also work for any console
> implementation, not just fbcon.
>
> If console detached this way and there was nothing to fallback to
> (systems without VGAcon), it would know not to try and print anything
> until something reattaches to it.

Another thought, controlling whether console is attached or not is an
attribute of console, not of fbcon. It should be possible to have
VGAcon, fbcon, serial etc loaded and then switch console between them.
Does console need to get a sysfs entry showing what console providers
have registered with it and then allow you to choose which one (or
none) it is attached to?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> > Overall, this feature is a great help for developers working in the
>> > framebuffer or console layer.  There is not need to continually
>> reboot the
>> > kernel for every small change. It is also useful for regular users
>> who wants
>> > to choose between a graphical console or a text console without
>> having to
>> > reboot.
>>
>> Instead of the sysfs attribute, what about creating a new escape
>> sequence that you send to the console system to detach? Doing it that
>> way would make more sense from a stacking order. It just seems
>> backwards to me that you ask a lower layer to detach from the layer
>> above it. The escape sequence would also work for any console
>> implementation, not just fbcon.
>>
>> If console detached this way and there was nothing to fallback to
>> (systems without VGAcon), it would know not to try and print anything
>> until something reattaches to it.
> 
> Another thought, controlling whether console is attached or not is an
> attribute of console, not of fbcon.

If the console attached fbcon, then I agree that console should decide
when to detach fbcon.  But that's not what happens, it's fbcon that
attaches itself.

It's not that you're wrong, it's just how the current vt/console layer
works.  If someone do decide to add this feature to the vt/console layer,
then I'm more than willing to have fbcon support that as well.
  
Tony

Re: [PATCH 0/7] Detaching fbcon

[Jon Smirl]

On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> > Overall, this feature is a great help for developers working in the
> >> > framebuffer or console layer.  There is not need to continually
> >> reboot the
> >> > kernel for every small change. It is also useful for regular users
> >> who wants
> >> > to choose between a graphical console or a text console without
> >> having to
> >> > reboot.
> >>
> >> Instead of the sysfs attribute, what about creating a new escape
> >> sequence that you send to the console system to detach? Doing it that
> >> way would make more sense from a stacking order. It just seems
> >> backwards to me that you ask a lower layer to detach from the layer
> >> above it. The escape sequence would also work for any console
> >> implementation, not just fbcon.
> >>
> >> If console detached this way and there was nothing to fallback to
> >> (systems without VGAcon), it would know not to try and print anything
> >> until something reattaches to it.
> >
> > Another thought, controlling whether console is attached or not is an
> > attribute of console, not of fbcon.
>
> If the console attached fbcon, then I agree that console should decide
> when to detach fbcon.  But that's not what happens, it's fbcon that
> attaches itself.
>
> It's not that you're wrong, it's just how the current vt/console layer
> works.  If someone do decide to add this feature to the vt/console layer,
> then I'm more than willing to have fbcon support that as well.

This is just kind of twisted since console increments the fbcon ref
count. Is /dev/console a real device, it that where the sysfs
attribute should go?

How is the stack maintained of what was previously bound to console?
What if I unbind fbcon on a system that doesn't have VGAcon for a backup?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 0/7] Detaching fbcon

[Dave Airlie]

> > >
> How is the stack maintained of what was previously bound to console?
> What if I unbind fbcon on a system that doesn't have VGAcon for a backup?

You could try actually reading the patches...

Dave.

Re: [PATCH 0/7] Detaching fbcon

[Jon Smirl]

On 6/6/06, Dave Airlie <airlied@gmail.com> wrote:
> > > >
> > How is the stack maintained of what was previously bound to console?
> > What if I unbind fbcon on a system that doesn't have VGAcon for a backup?
>
> You could try actually reading the patches...

I was working on a patch for this but now I've lost interest.

Detach should be an attribute off from /dev/console. /dev/console is
using the standard device support and appears at
/sys/class/tty/console so /sys/class/tty/console/detach can be added
as an attribute. /sys/class/tty/console could have another attribute
which lists the available drivers. One solution would be for the
attribute to list the names of the available drivers that have
registered with console and then copy one of those names back to the
attribute to select where console is bound.

In my opinion attach/detach does not belong as an attribute on fbcon,
it is part of /dev/console. The fact that fbcon has to ask console to
unbind from it implies these attributes are in the wrong place.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/6/06, Dave Airlie <airlied@gmail.com> wrote:
>> > > >
>> > How is the stack maintained of what was previously bound to console?
>> > What if I unbind fbcon on a system that doesn't have VGAcon for a
>> backup?
>>
>> You could try actually reading the patches...
> 
> I was working on a patch for this but now I've lost interest.

How come? I never believed you're the type to lose interest so easily :-)

> 
> Detach should be an attribute off from /dev/console. /dev/console is
> using the standard device support and appears at
> /sys/class/tty/console so /sys/class/tty/console/detach can be added
> as an attribute. /sys/class/tty/console could have another attribute
> which lists the available drivers. One solution would be for the
> attribute to list the names of the available drivers that have
> registered with console and then copy one of those names back to the
> attribute to select where console is bound.
> 
> In my opinion attach/detach does not belong as an attribute on fbcon,
> it is part of /dev/console. The fact that fbcon has to ask console to
> unbind from it implies these attributes are in the wrong place.

Okay, you and Andrew persuaded me to change the location of the control.
I did say that if someone makes the necessary change to the vt layer that
it won't be a problem. The necessary infrastructure is already introduced
by this patch to make it work like what you and Andrew want. 

Tony
 

Re: [PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/6/06, Jon Smirl <jonsmirl@gmail.com> wrote:
>> >> On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> > Overall, this feature is a great help for developers working in the
>> >> > framebuffer or console layer.  There is not need to continually
>> >> reboot the
>> >> > kernel for every small change. It is also useful for regular users
>> >> who wants
>> >> > to choose between a graphical console or a text console without
>> >> having to
>> >> > reboot.
>> >>
>> >> Instead of the sysfs attribute, what about creating a new escape
>> >> sequence that you send to the console system to detach? Doing it that
>> >> way would make more sense from a stacking order. It just seems
>> >> backwards to me that you ask a lower layer to detach from the layer
>> >> above it. The escape sequence would also work for any console
>> >> implementation, not just fbcon.
>> >>
>> >> If console detached this way and there was nothing to fallback to
>> >> (systems without VGAcon), it would know not to try and print anything
>> >> until something reattaches to it.
>> >
>> > Another thought, controlling whether console is attached or not is an
>> > attribute of console, not of fbcon.
>>
>> If the console attached fbcon, then I agree that console should decide
>> when to detach fbcon.  But that's not what happens, it's fbcon that
>> attaches itself.
>>
>> It's not that you're wrong, it's just how the current vt/console layer
>> works.  If someone do decide to add this feature to the vt/console layer,
>> then I'm more than willing to have fbcon support that as well.
> 
> This is just kind of twisted since console increments the fbcon ref
> count.

Oh, the console and vt layer is exactly that, twisted :-)

> Is /dev/console a real device, it that where the sysfs
> attribute should go?

We have /sys/class/tty/console.

 
> How is the stack maintained of what was previously bound to console?

That's the problem, there is no stack.  Once a driver binds to a console,
the previous driver is lost.

> What if I unbind fbcon on a system that doesn't have VGAcon for a backup?

All systems have a backup console, otherwise you're system won't boot.
It's either vgacon or dummycon.

Tony
Tony
 

Re: [PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

Jon Smirl wrote:
> On 6/6/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Overall, this feature is a great help for developers working in the
>> framebuffer or console layer.  There is not need to continually reboot
>> the
>> kernel for every small change. It is also useful for regular users who
>> wants
>> to choose between a graphical console or a text console without having to
>> reboot.
> 
> Instead of the sysfs attribute, what about creating a new escape
> sequence that you send to the console system to detach? Doing it that
> way would make more sense from a stacking order. It just seems
> backwards to me that you ask a lower layer to detach from the layer
> above it.

It is not the vt layer that attaches fbcon, it's fbcon that attaches
to the vt layer. So it is more logical that fbcon detaches itself, not
the other way around.
 
Tony

Re: [PATCH 0/7] Detaching fbcon

[Knut Petersen]

Antonino A. Daplas wrote:

>Overall, this feature is a great help for developers working in the
>framebuffer or console layer.  
>
Well, it has long been possible to load / unload framebuffer hardware
drivers using the vfb module as an intermediate step. It even has been
possible to load both vesafb and another framebuffer driver for the same
hardware, to assign vesafb to tty{a,b,c..}, the other framebuffer driver
to tty{m,n,o...} and to switch between those drivers using the usual
keyboard hotkeys.

So the main addition of your patchset is the possibility to replace
fbcon and helper modules, a nice feature I missed in the past.

But should a framebuffer driver terminate and leave the hardware in
graphics mode or in text mode? Up to now that was not a real question,
as we all knew that another framebuffer driver would take over control.
With your patches it is possible that a user really wants to switch to text
mode and to remove the complete fbcon layer. So should we switch the
hardware to text mode upon unloading a framebuffer driver?

Maybe unbinding of the framebuffer console is not followed by an
unloading of the framebuffer module. You tell us that an
"echo 1 > /sys/class/graphics/fbcon/detach" has the simple effect of a
corrupt display unless vbetools is used. No, that´s not ok.

Think about an echo 1 > /sys/class/graphics/fbcon/detach inside of an
xterm session.

I think we need new fbops, eg.

    int fb_fbcon_unbind(...)
    int fb_fbcon_bind(...)

If these are not implemented, unbinding is not allowed. Any requests to do
so will be ignored.

If these are implemented the fbcon_unbind() function of the framebuffer
driver is called first. If it does not return an error, unbinding can 
continue,
otherwise it fails.

With implemented fb_restore_state() and fb_save_state() fbops the 
framebuffer
driver knows best about the current hardware state and can act in a way that
there is no need for vbetools & friends as well as no possibility of fatal
interactions with X.

Unbinding requests should only be honored if the framebuffer driver decides
that it is safe. Don´t enable it by default.

cu,
 knut

Re: [PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

Knut Petersen wrote:
> Antonino A. Daplas wrote:
> 
>> Overall, this feature is a great help for developers working in the
>> framebuffer or console layer.  
>>
> Well, it has long been possible to load / unload framebuffer hardware
> drivers using the vfb module as an intermediate step. It even has been
> possible to load both vesafb and another framebuffer driver for the same
> hardware, to assign vesafb to tty{a,b,c..}, the other framebuffer driver
> to tty{m,n,o...} and to switch between those drivers using the usual
> keyboard hotkeys.
> 
> So the main addition of your patchset is the possibility to replace
> fbcon and helper modules, a nice feature I missed in the past.
> 
> But should a framebuffer driver terminate and leave the hardware in
> graphics mode or in text mode? Up to now that was not a real question,
> as we all knew that another framebuffer driver would take over control.
> With your patches it is possible that a user really wants to switch to text
> mode and to remove the complete fbcon layer. So should we switch the
> hardware to text mode upon unloading a framebuffer driver?
> 
> Maybe unbinding of the framebuffer console is not followed by an
> unloading of the framebuffer module. You tell us that an
> "echo 1 > /sys/class/graphics/fbcon/detach" has the simple effect of a
> corrupt display unless vbetools is used. No, that´s not ok.
> 
> Think about an echo 1 > /sys/class/graphics/fbcon/detach inside of an
> xterm session.
> 
> I think we need new fbops, eg.
> 
>     int fb_fbcon_unbind(...)
>     int fb_fbcon_bind(...)
> 
> If these are not implemented, unbinding is not allowed. Any requests to do
> so will be ignored.

We'll use fb_restore_state and fb_save_state if available, yes, but I don't
think we need to implement unbind and bind.  For one, as Jon and Andrew
has pointed out, drivers should have no concept of binding. (That's why the
patch has escalated to VT binding).

And why force drivers to have an fb_restore_state/fb_save_state just to
unbind/bind?  This is going to penalize 10's of drivers that don't need
it.  Just make this feature an experimental kconfig option, or make this
available as a boot option.

This feature is in a state of flux, so this is definitely not its final
form, nor the last one in a series.  The main goal here is to make the fbdev
system synchronize with other tools/modules whether it be for state
preservation, assistance on mode setting, etc. We need this if we are going
to make the different architectures work together.

Tony

Re: [PATCH 0/7] Detaching fbcon

[Knut Petersen]

Hi Tony,

>We'll use fb_restore_state and fb_save_state if available, yes, but I don't
>think we need to implement unbind and bind.  For one, as Jon and Andrew
>has pointed out, drivers should have no concept of binding. (That's why the
>patch has escalated to VT binding).
>
>  
>
Well, it does not matter if it´s the fbcon or vt layer that does the
binding. I agree with Jon and Andrew that vt binding is the better
way.

>And why force drivers to have an fb_restore_state/fb_save_state just to
>unbind/bind?  This is going to penalize 10's of drivers that don't need
>it.  Just make this feature an experimental kconfig option, or make this
>available as a boot option.
>  
>
An experimental feature could be "Allow all framebuffer drivers to unbind".
Non-experimental behaviour really should be to allow unbinding
only if the framebuffer driver allows it. The fbcon and vt layer simply
does not know if it is safe, and thus they have to interrogate the
hardware layer that knows the answer.

Your current proposal is to allow unbinding and removal of the framebuffer
driver and the fbcon layer, no matter what the result will be. I don´t think
that this is ok.  There is  John User that tries to switch to text mode, and
he will complain if it does leave his hardware in an unusable state.

I suggest to add the fb_unbinding / fb_binding fbops and to only allow
unbinding if we know that it will not leave the video hardware in a state
that is unusable for proper operation.

If there is nothing to be done inside those two fbops, they simply return
0.

Other framebuffer drivers set the hardware to a state that is completely
unusable by a textmode console and that is incompatible with X. These
might need to know if X is active to decide if unbinding makes any sense at
that specific moment. They can know that by adding the save/restore_state
fbops. No, I don´t think that the save/restore_state fbops should be 
required
for unbinding operations, I think you misunderstood me in that place.

cu,
 knut

Re: [PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

Knut Petersen wrote:
> Hi Tony,
> 
>> We'll use fb_restore_state and fb_save_state if available, yes, but I don't
>> think we need to implement unbind and bind.  For one, as Jon and Andrew
>> has pointed out, drivers should have no concept of binding. (That's why the
>> patch has escalated to VT binding).
>>
>>  
>>
> Well, it does not matter if it´s the fbcon or vt layer that does the
> binding. I agree with Jon and Andrew that vt binding is the better
> way.
> 
>> And why force drivers to have an fb_restore_state/fb_save_state just to
>> unbind/bind?  This is going to penalize 10's of drivers that don't need
>> it.  Just make this feature an experimental kconfig option, or make this
>> available as a boot option.
>>  
>>
> An experimental feature could be "Allow all framebuffer drivers to unbind".

Yes, this was what I meant.

> Non-experimental behaviour really should be to allow unbinding
> only if the framebuffer driver allows it. The fbcon and vt layer simply
> does not know if it is safe, and thus they have to interrogate the
> hardware layer that knows the answer.
> 
> Your current proposal is to allow unbinding and removal of the framebuffer
> driver and the fbcon layer, no matter what the result will be. I don´t think
> that this is ok.  There is  John User that tries to switch to text mode, and
> he will complain if it does leave his hardware in an unusable state.

This I disagree with you.  The view that an operation should be totally
done 100% within the kernel is very utopic.  We already have features that
require both the kernel and userspace for them to work. The nearest example
is suspend/resume. It's good if you can make suspend/resume work without
additional effort, but that's not the case. Majority of users still need
utilities such as vbetool.

> 
> I suggest to add the fb_unbinding / fb_binding fbops and to only allow
> unbinding if we know that it will not leave the video hardware in a state
> that is unusable for proper operation.
> 
> If there is nothing to be done inside those two fbops, they simply return
> 0.
> 
> Other framebuffer drivers set the hardware to a state that is completely
> unusable by a textmode console and that is incompatible with X. These
> might need to know if X is active to decide if unbinding makes any sense at
> that specific moment.

This is very ugly. Drivers should not care whether it's safe to load or
unload, unbind or bind, or whether a specific application is open or not.
This is not their job, this should be the job of the higher layer or an
arbiter.  And yes, the state of graphics is currently ugly, witness the
very long threads on how to to make everything work together.

Right now, the only thing I can claim is that trying to do an fbdev
operation while inside X will result in undefined, if not fatal behavior.
Don't do it. And no matter how many ugly hacks and workarounds we add
for the framebuffer layer, this will always be true.

Tony

Re: [PATCH 0/7] Detaching fbcon

[Geert Uytterhoeven]

On Mon, 12 Jun 2006, Antonino A. Daplas wrote:
> Knut Petersen wrote:
> > I suggest to add the fb_unbinding / fb_binding fbops and to only allow
> > unbinding if we know that it will not leave the video hardware in a state
> > that is unusable for proper operation.
> > 
> > If there is nothing to be done inside those two fbops, they simply return
> > 0.
> > 
> > Other framebuffer drivers set the hardware to a state that is completely
> > unusable by a textmode console and that is incompatible with X. These
> > might need to know if X is active to decide if unbinding makes any sense at
> > that specific moment.
> 
> This is very ugly. Drivers should not care whether it's safe to load or
> unload, unbind or bind, or whether a specific application is open or not.
> This is not their job, this should be the job of the higher layer or an
> arbiter.  And yes, the state of graphics is currently ugly, witness the
> very long threads on how to to make everything work together.
> 
> Right now, the only thing I can claim is that trying to do an fbdev
> operation while inside X will result in undefined, if not fatal behavior.
> Don't do it. And no matter how many ugly hacks and workarounds we add
> for the framebuffer layer, this will always be true.

The main problem is that there are too many drivers for the same hardware:
  - vgacon
  - fbdev
  - X

All of them want to control the hardware, and all of them make assumptions
about its state...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH 0/7] Detaching fbcon

[Michal Suchanek]

On 6/12/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > Non-experimental behaviour really should be to allow unbinding
> > only if the framebuffer driver allows it. The fbcon and vt layer simply
> > does not know if it is safe, and thus they have to interrogate the
> > hardware layer that knows the answer.
> >
> > Your current proposal is to allow unbinding and removal of the framebuffer
> > driver and the fbcon layer, no matter what the result will be. I don´t think
> > that this is ok.  There is  John User that tries to switch to text mode, and
> > he will complain if it does leave his hardware in an unusable state.
>
> This I disagree with you.  The view that an operation should be totally
> done 100% within the kernel is very utopic.  We already have features that
> require both the kernel and userspace for them to work. The nearest example
> is suspend/resume. It's good if you can make suspend/resume work without
> additional effort, but that's not the case. Majority of users still need
> utilities such as vbetool.

Well, I guess that the fb driver should try to restore the original
mode (ie text mode on x86) on unload. And it is either considered
flawed if it doesnt or it should indicate somewhere that it does not
know how to unload itself.

That is what I as a user would expect. But I do not expect all drivers
to be flawless at all times. It would be nice but it does not happen.

>
> >
> > I suggest to add the fb_unbinding / fb_binding fbops and to only allow
> > unbinding if we know that it will not leave the video hardware in a state
> > that is unusable for proper operation.
> >
> > If there is nothing to be done inside those two fbops, they simply return
> > 0.
> >
> > Other framebuffer drivers set the hardware to a state that is completely
> > unusable by a textmode console and that is incompatible with X. These
> > might need to know if X is active to decide if unbinding makes any sense at
> > that specific moment.
>
> This is very ugly. Drivers should not care whether it's safe to load or
> unload, unbind or bind, or whether a specific application is open or not.
> This is not their job, this should be the job of the higher layer or an
> arbiter.  And yes, the state of graphics is currently ugly, witness the
> very long threads on how to to make everything work together.
>
> Right now, the only thing I can claim is that trying to do an fbdev
> operation while inside X will result in undefined, if not fatal behavior.
> Don't do it. And no matter how many ugly hacks and workarounds we add
> for the framebuffer layer, this will always be true.

I like the possibility to change X resolution using fbset (from inside
X). I use it to correct problems caused by crashed X programs that
change resolution. But I run X with the UseFbDev option. The X server
would be probably quite unhappy if I removed the fb driver but since
it uses the fb device the driver should not unload.

I guess that if X changes settings of the graphics card and does not
tell the fb driver the cooperation would not be that nice. But that's
X problem then I think.

Thanks

Michal

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

Re: [Linux-fbdev-devel] [PATCH 0/7] Detaching fbcon

[Antonino A. Daplas]

Michal Suchanek wrote:
> On 6/12/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>>> Non-experimental behaviour really should be to allow unbinding
>>> only if the framebuffer driver allows it. The fbcon and vt layer simply
>>> does not know if it is safe, and thus they have to interrogate the
>>> hardware layer that knows the answer.
>>>
>>> Your current proposal is to allow unbinding and removal of the framebuffer
>>> driver and the fbcon layer, no matter what the result will be. I don´t think
>>> that this is ok.  There is  John User that tries to switch to text mode, and
>>> he will complain if it does leave his hardware in an unusable state.
>> This I disagree with you.  The view that an operation should be totally
>> done 100% within the kernel is very utopic.  We already have features that
>> require both the kernel and userspace for them to work. The nearest example
>> is suspend/resume. It's good if you can make suspend/resume work without
>> additional effort, but that's not the case. Majority of users still need
>> utilities such as vbetool.
> 
> Well, I guess that the fb driver should try to restore the original
> mode (ie text mode on x86) on unload. And it is either considered
> flawed if it doesnt or it should indicate somewhere that it does not
> know how to unload itself.

Well, failure to implement proper suspend and resume by a driver does not
stop the entire suspend/resume process, does it? Even if it results
in a blank screen. It doesn't because we have a userspace options and
tools that complements the kernel side. So why should it be any different
in this case? 

Some drivers, i810fb and rivafb, saves the hardware state on the
first open, and restores the hardware state on the last close. This
is usually sufficient for them to restore the hardware to VGA text
mode on unload. It would be nice if we can implement something like this
for all drivers, but failure to do so should not be a reason to stop the
entire process.

> I like the possibility to change X resolution using fbset (from inside
> X). I use it to correct problems caused by crashed X programs that
> change resolution. But I run X with the UseFbDev option. The X server
> would be probably quite unhappy if I removed the fb driver but since
> it uses the fb device the driver should not unload.

If X is using fbdev, then X is also holding a reference count on the
driver.  And the driver will not unload even if you try to.

Tony

Re: [PATCH 0/7] Detaching fbcon

[Michal Suchanek]

On 6/12/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Michal Suchanek wrote:
> > On 6/12/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >>> Non-experimental behaviour really should be to allow unbinding
> >>> only if the framebuffer driver allows it. The fbcon and vt layer simply
> >>> does not know if it is safe, and thus they have to interrogate the
> >>> hardware layer that knows the answer.
> >>>
> >>> Your current proposal is to allow unbinding and removal of the framebuffer
> >>> driver and the fbcon layer, no matter what the result will be. I don´t think
> >>> that this is ok.  There is  John User that tries to switch to text mode, and
> >>> he will complain if it does leave his hardware in an unusable state.
> >> This I disagree with you.  The view that an operation should be totally
> >> done 100% within the kernel is very utopic.  We already have features that
> >> require both the kernel and userspace for them to work. The nearest example
> >> is suspend/resume. It's good if you can make suspend/resume work without
> >> additional effort, but that's not the case. Majority of users still need
> >> utilities such as vbetool.
> >
> > Well, I guess that the fb driver should try to restore the original
> > mode (ie text mode on x86) on unload. And it is either considered
> > flawed if it doesnt or it should indicate somewhere that it does not
> > know how to unload itself.
>
> Well, failure to implement proper suspend and resume by a driver does not
> stop the entire suspend/resume process, does it? Even if it results
> in a blank screen. It doesn't because we have a userspace options and
> tools that complements the kernel side. So why should it be any different
> in this case?

I do not say it must be different. vgacon (or whatever is the text
console called) fails to do proper suspend/resume for me. I just use X
and think the console is flawed. However, it would be nice if I was
warned in advance that the console will die on suspend.

>
> Some drivers, i810fb and rivafb, saves the hardware state on the
> first open, and restores the hardware state on the last close. This
> is usually sufficient for them to restore the hardware to VGA text
> mode on unload. It would be nice if we can implement something like this
> for all drivers, but failure to do so should not be a reason to stop the
> entire process.
>
> > I like the possibility to change X resolution using fbset (from inside
> > X). I use it to correct problems caused by crashed X programs that
> > change resolution. But I run X with the UseFbDev option. The X server
> > would be probably quite unhappy if I removed the fb driver but since
> > it uses the fb device the driver should not unload.
>
> If X is using fbdev, then X is also holding a reference count on the
> driver.  And the driver will not unload even if you try to.

yes, that's it. And if it does not it is X problem. Not fb problem.


Thanks

Michal

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

Re: [Linux-fbdev-devel] [PATCH 0/7] Detaching fbcon

[Michel Dänzer]

On Mon, 2006-06-12 at 15:28 +0200, Michal Suchanek wrote:
> 
> I like the possibility to change X resolution using fbset (from inside
> X). I use it to correct problems caused by crashed X programs that
> change resolution. But I run X with the UseFbDev option.

Still, you should use something like xrandr instead, so the X server
knows about it.


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

Re: [PATCH 0/7] Detaching fbcon

[Michal Suchanek]

On 6/12/06, Michel Dänzer <michel@tungstengraphics.com> wrote:
> On Mon, 2006-06-12 at 15:28 +0200, Michal Suchanek wrote:
> >
> > I like the possibility to change X resolution using fbset (from inside
> > X). I use it to correct problems caused by crashed X programs that
> > change resolution. But I run X with the UseFbDev option.
>
> Still, you should use something like xrandr instead, so the X server
> knows about it.

I have never heared of a tool for X that does it. Fbset is here
already and works well.

Thanks

Michal

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

Re: [PATCH 0/7] Detaching fbcon

[Michel Dänzer]

On Mon, 2006-06-12 at 18:46 +0200, Michal Suchanek wrote:
> On 6/12/06, Michel Dänzer <michel@tungstengraphics.com> wrote:
> > On Mon, 2006-06-12 at 15:28 +0200, Michal Suchanek wrote:
> > >
> > > I like the possibility to change X resolution using fbset (from inside
> > > X). I use it to correct problems caused by crashed X programs that
> > > change resolution. But I run X with the UseFbDev option.
> >
> > Still, you should use something like xrandr instead, so the X server
> > knows about it.
> 
> I have never heared of a tool for X that does it.

Well, now you have. :) Unless you have a different problem, but xrandr
has always worked for me in the situations you describe above.


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




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