From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-06 11:10:19
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.
From: Jon Smirl <hidden> Date: 2006-06-06 16:10:42
On 6/6/06, Antonino A. Daplas [off-list ref] 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
From: Jon Smirl <hidden> Date: 2006-06-06 16:19:37
On 6/6/06, Jon Smirl [off-list ref] wrote:
On 6/6/06, Antonino A. Daplas [off-list ref] wrote:
quoted
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-06 19:45:36
Jon Smirl wrote:
On 6/6/06, Antonino A. Daplas [off-list ref] wrote:
quoted
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-06 19:45:59
Jon Smirl wrote:
On 6/6/06, Jon Smirl [off-list ref] wrote:
quoted
On 6/6/06, Antonino A. Daplas [off-list ref] wrote:
quoted
Overall, this feature is a great help for developers working in the
framebuffer or console layer. There is not need to continually
reboot the
quoted
kernel for every small change. It is also useful for regular users
who wants
quoted
to choose between a graphical console or a text console without
having to
quoted
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
From: Jon Smirl <hidden> Date: 2006-06-06 21:00:38
On 6/6/06, Antonino A. Daplas [off-list ref] wrote:
Jon Smirl wrote:
quoted
On 6/6/06, Jon Smirl [off-list ref] wrote:
quoted
On 6/6/06, Antonino A. Daplas [off-list ref] wrote:
quoted
Overall, this feature is a great help for developers working in the
framebuffer or console layer. There is not need to continually
reboot the
quoted
kernel for every small change. It is also useful for regular users
who wants
quoted
to choose between a graphical console or a text console without
having to
quoted
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
From: Jon Smirl <hidden> Date: 2006-06-06 21:56:55
On 6/6/06, Dave Airlie [off-list ref] wrote:
quoted
quoted
quoted
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-06 23:17:33
Jon Smirl wrote:
On 6/6/06, Dave Airlie [off-list ref] wrote:
quoted
quoted
quoted
quoted
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-06 23:17:53
Jon Smirl wrote:
On 6/6/06, Antonino A. Daplas [off-list ref] wrote:
quoted
Jon Smirl wrote:
quoted
On 6/6/06, Jon Smirl [off-list ref] wrote:
quoted
On 6/6/06, Antonino A. Daplas [off-list ref] wrote:
quoted
Overall, this feature is a great help for developers working in the
framebuffer or console layer. There is not need to continually
reboot the
quoted
kernel for every small change. It is also useful for regular users
who wants
quoted
to choose between a graphical console or a text console without
having to
quoted
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
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-11 22:04:25
Knut Petersen wrote:
Antonino A. Daplas wrote:
quoted
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
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-12 12:17:37
Knut Petersen wrote:
Hi Tony,
quoted
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.
quoted
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
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
From: Michal Suchanek <hidden> Date: 2006-06-12 13:28:31
On 6/12/06, Antonino A. Daplas [off-list ref] wrote:
quoted
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.
quoted
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-06-12 14:16:08
Michal Suchanek wrote:
On 6/12/06, Antonino A. Daplas [off-list ref] wrote:
quoted
quoted
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
From: Michel Dänzer <hidden> Date: 2006-06-12 14:20:20
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
From: Michal Suchanek <hidden> Date: 2006-06-12 16:44:48
On 6/12/06, Antonino A. Daplas [off-list ref] wrote:
Michal Suchanek wrote:
quoted
On 6/12/06, Antonino A. Daplas [off-list ref] wrote:
quoted
quoted
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.
quoted
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
From: Michal Suchanek <hidden> Date: 2006-06-12 16:46:54
On 6/12/06, Michel Dänzer [off-list ref] wrote:
On Mon, 2006-06-12 at 15:28 +0200, Michal Suchanek wrote:
quoted
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
From: Michel Dänzer <hidden> Date: 2006-06-12 17:20:34
On Mon, 2006-06-12 at 18:46 +0200, Michal Suchanek wrote:
On 6/12/06, Michel Dänzer [off-list ref] wrote:
quoted
On Mon, 2006-06-12 at 15:28 +0200, Michal Suchanek wrote:
quoted
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