Detaching fbcon
cover Detaching fbcon
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.
Quoted 5 lines · Antonino A. Daplas
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 14 lines · Jon Smirl
Quoted 5 lines · Antonino A. Daplas
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.
Quoted 3 lines
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?
Signature · 2 lines
Jon Smirl [email protected]
Quoted 18 lines · Jon Smirl
Quoted 17 lines · Jon Smirl
Quoted 2 lines · Antonino A. Daplas
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 1 line
kernel for every small change. It is also useful for regular users
who wants
Quoted 1 line
to choose between a graphical console or a text console without
having to
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 26 lines · Antonino A. Daplas
Quoted 18 lines · Jon Smirl
Quoted 17 lines · Jon Smirl
Quoted 2 lines · Antonino A. Daplas
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 1 line
kernel for every small change. It is also useful for regular users
who wants
Quoted 1 line
to choose between a graphical console or a text console without
having to
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
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?
Signature · 2 lines
Jon Smirl [email protected]
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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.
Quoted 5 lines · Dave Airlie
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 9 lines · Jon Smirl
Quoted 6 lines · Dave Airlie
Quoted 3 lines
Quoted 1 line
Quoted 1 line
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 :-)
Quoted 10 lines
Detach should be an attribute off from
/dev/console./dev/consoleis using the standard device support and appears at/sys/class/tty/consoleso/sys/class/tty/console/detachcan be added as an attribute./sys/class/tty/consolecould 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.
Quoted 3 lines
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
Quoted 31 lines · Jon Smirl
Quoted 30 lines · Antonino A. Daplas
Quoted 18 lines · Jon Smirl
Quoted 17 lines · Jon Smirl
Quoted 2 lines · Antonino A. Daplas
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 1 line
kernel for every small change. It is also useful for regular users
who wants
Quoted 1 line
to choose between a graphical console or a text console without
having to
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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 :-)
Quoted 2 lines
Is
/dev/consolea real device, it that where the sysfs attribute should go?
We have /sys/class/tty/console.
Quoted 1 line
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.
Quoted 1 line
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
Quoted 9 lines · Jon Smirl
Quoted 7 lines · Antonino A. Daplas
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.
Quoted 5 lines
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
Quoted 3 lines · Antonino A. Daplas
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
Quoted 30 lines · Knut Petersen
Quoted 3 lines · Antonino A. Daplas
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/detachinside of an xterm session.
Quoted 7 lines
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
Hi Tony,
Quoted 7 lines
We'll use
fb_restore_stateandfb_save_stateif 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 6 lines
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
Quoted 13 lines · Knut Petersen
Hi Tony,
Quoted 7 lines
We'll use
fb_restore_stateandfb_save_stateif 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 7 lines
Quoted 6 lines
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.
Quoted 9 lines
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.
Quoted 5 lines
I suggest to add the
fb_unbinding/fb_bindingfbops 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.
Quoted 7 lines
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
Quoted 19 lines · Antonino A. Daplas
Quoted 11 lines · Knut Petersen
I suggest to add the
fb_unbinding/fb_bindingfbops 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.
Quoted 4 lines
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 -- [email protected]
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
Quoted 10 lines · Antonino A. Daplas
Quoted 9 lines
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.
Quoted 6 lines
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 20 lines
Quoted 6 lines
I suggest to add the
fb_unbinding/fb_bindingfbops 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.Quoted 7 lines
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.
Quoted 4 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
Quoted 17 lines · Michal Suchanek
Quoted 9 lines · Antonino A. Daplas
Quoted 9 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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
Quoted 23 lines · Antonino A. Daplas
Quoted 17 lines · Michal Suchanek
Quoted 9 lines · Antonino A. Daplas
Quoted 9 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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 8 lines
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
Quoted 4 lines · Michal Suchanek
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.
Signature · 2 lines
Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Quoted 8 lines · Michel Dänzer
Quoted 4 lines · Michal Suchanek
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
Quoted 11 lines · Michal Suchanek
Quoted 8 lines · Michel Dänzer
Quoted 4 lines · Michal Suchanek
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.
Signature · 10 lines
Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ Linux-fbdev-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel