Menu
▾
▴
linuxconsole-dev
|
From: James S. <jsi...@li...> - 2001-03-15 04:46:02
|
>>So the fbdev drivers would register PM with fbcon, not PCI, correct? > >Either that, or the fbdev would register with PCI (or whatever), _and_ >fbcon would too independently. In that scenario, fbcon would only handle >things like disabling the cursor timer, while fbdev's would handle HW >issues. THe only problem is for fbcon to know that a given fbdev is >asleep, this could be an exported per-fbdev flag, an error code, or >whatever. In this case, fbcon can either buffer text input, or fallback >to the cfb working on the backed up fb image (that last thing can be >handled entirely within the fbdev I guess). Hi! I had to give it some thought. I like to see this handles inside the fbdev driver itself instead of inside fbcon. For 2.5.X it will be possible to use /dev/fb with vgacon. Even better yet it will be possible to use just a serial console and not use a VT but still use /dev/fb. So we will want to to have fbdev doing power management itself. As for handling the cursors I recently purposed a standardize cursor api so X can use it as well via userland and a standard fbcon_cursor can be written. With this api it would be easy to handle suspending and restoring the cursor for fbcon for /dev/fb. As for fbcon knowing when it is asleep. Hum. We could have a flags to tell it to have text data updates to be placed in the shadow buffer (struct vc_datas->vc_screenbuffer) only; MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@li...> - 2001-03-15 05:17:34
|
>>I'd go for a fallback to dummycon. It's of no use to waste power on >>creating graphical images of the text console when asleep. And the >>fallback to dummycon is needed anyway while a fbdev is opened (in >>2.5.x). > >We do already have the backup image since we need to backup & restore the >framebuffer content. What he is talking about is in 2.5.X when you explictly open /dev/fb it will call take_over_console with dummy con. This allows for several things. One is with this approach their is no chance of a conflict between X/DRI and fbdev. Especially when we will have fbdev drivers using DMA internally to preform console operations. For some hardware using DMA is the only way fbdev can work and on some platforms fbcon is the only choice. So things going into /dev/ttyX will not have a chance to interfere with X. The second reason is for security. It is possible to have a program to open /dev/fb and see what is being typed on the fore ground console. I sealed up those holes using the dummy con approach and some test to see if the current process is local. Now for fbcon its simpler. Things get writing to the shadow buffer (vc_screenbuf). When the console gets woken up update_screen is called. While power down the shadow buffer can be written to which is much faster than saving a image of the framebuffer. Of course if you still want to do this such in the case of the X server then copy the image of the framebuffer to regular ram. Then power down /dev/fb using some ioctl calls provide. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Benjamin H. <be...@ke...> - 2001-03-15 11:29:54
|
> Now for fbcon its simpler. Things get writing to the shadow buffer >(vc_screenbuf). When the console gets woken up update_screen is called. >While power down the shadow buffer can be written to which is much faster >than saving a image of the framebuffer. Of course if you still want to do >this such in the case of the X server then copy the image of the >framebuffer to regular ram. Then power down /dev/fb using some ioctl calls >provide. Ok, I see. Currently, the sleep process is started from an ioctl sent to another driver, which will in turn call various notifier functions to shut down bits of hardware and finally put the machine to sleep. It's not a direct ioctl to the /dev/fb (which may not be opened). One problem I have is that my fbdev sleep routine will restore the mode on wakeup, but that of course doesn't work with X when not using useFBDev as fbdev have no knowledge of the current mode or register settings used by X. I'm wondering if it would be possible to make X think there's a console switch (without actually switching to an active console, as we don't know if we even have one of those available for us), wait for it to reply, and then start the sleep process. One other possibility would be to implement APM-like events, I still have to study those more in details as our sleep process is currently quite different from APM (and definitely not BIOS-based). For now, I have my hooks in fbcon that suspend/restart the cursor timer, that's enough to make sleep stable on 2.4 since we take care of shutting down the display very last (after any other driver) to make sure no printk will end up trying to display something while the chip is powered down. I'll digest your various comments look into all this in more depth with 2.5 console codebase. I beleive some solution must be found for x86 laptops too. Ben. |
|
From: Geert U. <ge...@li...> - 2001-03-15 12:01:47
|
On Thu, 15 Mar 2001, Benjamin Herrenschmidt wrote:
> One problem I have is that my fbdev sleep routine will restore the mode
> on wakeup,
> but that of course doesn't work with X when not using useFBDev as fbdev
> have no
> knowledge of the current mode or register settings used by X.
That's a bug in X: one must not change the video mode by banging the hardware
when running on a fbdev system.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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: Russell K. <rm...@ar...> - 2001-03-15 22:27:50
|
On Thu, Mar 15, 2001 at 01:03:35PM +0100, Geert Uytterhoeven wrote:
> On Thu, 15 Mar 2001, Benjamin Herrenschmidt wrote:
> > One problem I have is that my fbdev sleep routine will restore the mode
> > on wakeup,
> > but that of course doesn't work with X when not using useFBDev as fbdev
> > have no
> > knowledge of the current mode or register settings used by X.
>
> That's a bug in X: one must not change the video mode by banging the hardware
> when running on a fbdev system.
That's not the only fbdev bug in X. I have been getting a lot of reports
which indicate that FBDev X does not turn off text mode acceleration when
it wants to switch into graphics mode.
As far as I know, the Debian people looking after the ARM FBDev package
haven't produced a patch for XFree for this particular problem yet.
However, it'd be nice to get it fixed by some means.
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
(who doesn't run XFree86... yet... but his original port of plain old X11R6)
|
|
From: James S. <jsi...@li...> - 2001-03-15 05:26:49
|
>But wouldn't falling back to dummycon prevent the driver specific >suspend/resume calls from working? Or at a minimum, make handling those >calls more complex? Not if suspend/resume are handled on the fbdev driver level. Dummycon would only shutdown fbcon on explict open of /dev/fb. Also note it will be possible to have only a serial console and use /dev/fb by itself. In this case we don't even need dummycon since their is no VT support present. >No, there does not need to be graphical images of the text console -- a >simply text buffer would suffice. See email to Ben. >But what about things like GTKFb and >Embedded QT? They would certainly benefit from having a backup screen >image, right? I do not believe there is any way to determine if the >console is in fact in a 'text' or graphical state. Yes and it would not be hard to do this. I have the basic idea in the email to Ben. As for console in text or graphical state take a look at vt_ioctl.c:vt_ioctl() for KDGETMODE. You get back KD_TEXT or KD_GRAPHICS. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@li...> - 2001-03-21 16:19:34
|
>That's not the only fbdev bug in X. I have been getting a lot of reports >which indicate that FBDev X does not turn off text mode acceleration when >it wants to switch into graphics mode. This will be fixed for 2.5.X. I'm working on a solution now. IMNSHO the kernel should manage switching from VGA text mode to some graphical mode and visa versa. Same for fbcon. Opening /dev/fb should manage shutdown the console system itself. One we can't count on XFree86 getting it right. Second I have seen reports of when X fails under heavy load or some other bizzare reason to properly reset the console itself. This leaves the machine in a useless state and requires a reboot. I'm also working on this. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@li...> - 2001-03-21 17:01:50
|
>Ok, I see. Currently, the sleep process is started from an ioctl sent to >another driver, which will in turn call various notifier functions to >shut down bits of hardware and finally put the machine to sleep. It's not >a direct ioctl to the /dev/fb (which may not be opened). [snip]... I need to ask you where is this code? I like to take a look at it to figure out what you are doing. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Benjamin H. <be...@ke...> - 2001-03-21 22:10:02
|
> > >I need to ask you where is this code? I like to take a look at it to >figure out what you are doing. You can find the mach64 sleep notifier in atyfb.c (under CONFIG_POWERBOOK) , the code that calls sleep notifiers is in drivers/macintosh/via-pmu.c (the various sleep functions). The current mach64 & chipsfb notifiers don't do anything to fbcon (they don't stop the cursor timer neither). I have some WIP progress code in my local tree that implements sleep support for more recent models with a notifier in aty128fb too. I added some fbcon suspend/resume routines for the cursor, but they are currently called from my aty128fb sleep notifier, which is wrong. Ben. |
|
From: James S. <jsi...@li...> - 2001-03-21 17:26:38
|
>I guess "support" routines can be provided by fbcon to switch to >dummycon. Hum. I had the idea of sharing the pm_dev between the console and fbdev. When the console goes to shutdown it automatically affect the pm_dev in fb_info for the fbdev driver. Vice versa is true. I have to think about it more. >it must of course not try to flash the cursor on an already sleeping >fbdev (handled by the switch to dummycon I beleive if we decide to do it >this way). Yes. take_over_console would hide the old_cursor and replace with the dummy_con cursor which doesn't exist. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@li...> - 2001-03-21 17:59:29
|
>> This will be fixed for 2.5.X. I'm working on a solution now. IMNSHO the
>> kernel should manage switching from VGA text mode to some graphical
>> mode and visa versa. Same for fbcon. Opening /dev/fb should manage
>> shutdown the console system itself.
>Should it? What happens if I run fbset to change the text resolution?
>When fbset opens /dev/fb, should the console really be shutdown?
Believe it not the functional allready exist in the tty layer to change
a video mode for a specific tty. It just has never been implemented in
linux. I have implemented it for my own kernel tree.
TIOCGWINSZ
TIOCSWINSZ
struct winsize {
unsigned short ws_row;
unsigned short ws_col;
unsigned short ws_xpixel;
unsigned short ws_ypixel;
};
The only thing is you can't change the depth using this approach. So what
do we do? FB_ACTIVATE_NXTOPEN :-) This signals to fbdev to preserve the
color depth for the console system. Once take_over_console is called it
will reinitalize the color palette for us. As for setting all the VCs we
have good old VT_RESIZE.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsi...@li...] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
|
|
From: Russell K. <rm...@ar...> - 2001-03-21 19:41:56
|
James Simmons writes:
> Believe it not the functional allready exist in the tty layer to change
> a video mode for a specific tty. It just has never been implemented in
> linux. I have implemented it for my own kernel tree.
> ...
> The only thing is you can't change the depth using this approach. So what
> do we do? FB_ACTIVATE_NXTOPEN :-) This signals to fbdev to preserve the
> color depth for the console system. Once take_over_console is called it
> will reinitalize the color palette for us. As for setting all the VCs we
> have good old VT_RESIZE.
Ewww, that means that all possible video modes must be listed in a table
in the kernel? I'd prefer to keep the current situation because it is
has the "policy" in user space, ie, the video programming information.
That seems like a great step backwards to me. For instance, how do you
handle the case where you want to support:
FBCon Text, 80x30 @ 50Hz
FBCon Text, 80x30 @ 60Hz
We already fully support this on ARM machines since one of the applications
of ARM boxen are web-top devices, which are required to produce TV
compatible signals.
Note that I'm not talking about a specialised embedded driver here, but one
that is used for machines which will do 1280x1024 @ 75Hz down to standard
TV signals without modifications. In fact, I'm using it at 1280x1024
right now. ;)
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@li...> - 2001-03-22 16:16:29
|
>Ewww, that means that all possible video modes must be listed in a table >in the kernel? No. Of course we kind of do that now with modedb. It is the same as now. The only difference is it goes threw the tty layer to the fbcon layer instead of from userland to fbdev layer to tty layer. It makes for a consistant interface for mode changing for all console drivers. It also allows for a resize_vc function which in turn allows for a generic VC switching function. No more con_switch is needed. The next benfiet is since it is coming from the tty layer we have modes of columns*font width by rows*font height. We don't need code to deal with case if the number of columns is 80 and 1/2. Now if we are stuck with a system where the card mode is set and can't be changed we then do the opposite and look for a font set that makes the mode perfect. If we can't find one well its time to provide a special font for that system. >I'd prefer to keep the current situation because it is has the "policy" >in user space, ie, the video programming information. Hah? Policy is still in userspace. You just express the resolution in columns and rows instead of pixels. You could express it in pixels as well since struct winsize allows this. I haven't implemented it yet since it also requires dealing with possible font handling. Yuck! >That seems like a great step backwards to me. For instance, how do you >handle the case where you want to support: > > FBCon Text, 80x30 @ 50Hz > FBCon Text, 80x30 @ 60Hz With FB_ACTIVATE_NXTOPEN. The question you have to ask yourself is why do you need this specifically if you are going to be using fbdev only as a text console ? [below] >We already fully support this on ARM machines since one of theapplications >of ARM boxen are web-top devices, which are required to produce TV >compatible signals. Are you still using fbdev just as a text console here or are we talking here a app that opens /dev/fb and uses /dev/fb. If that is the case then the card is the only limit. If not and for some reason you need the graphical console while needing to produce TV compatiable signals then you can a) Make the default fb_var_screeninfo compatible to produce TV signals in the driver. b) Use modedb to select the mode you want. c) Open /dev/fb but use the FB_ACTIVATE_NXTOPEN flag to preserve the hardware state to what you want when going back to fbcon. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@li...> - 2001-03-22 16:18:57
|
Thansk for the code. Now I go think. Ugh! MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Geert U. <ge...@li...> - 2001-03-15 08:19:11
|
On Wed, 14 Mar 2001, James Simmons wrote:
> >>So the fbdev drivers would register PM with fbcon, not PCI, correct?
> >
> >Either that, or the fbdev would register with PCI (or whatever), _and_
> >fbcon would too independently. In that scenario, fbcon would only handle
> >things like disabling the cursor timer, while fbdev's would handle HW
> >issues. THe only problem is for fbcon to know that a given fbdev is
> >asleep, this could be an exported per-fbdev flag, an error code, or
> >whatever. In this case, fbcon can either buffer text input, or fallback
> >to the cfb working on the backed up fb image (that last thing can be
> >handled entirely within the fbdev I guess).
[...]
> As for fbcon knowing when it is asleep. Hum. We could have a flags to
> tell it to have text data updates to be placed in the shadow buffer
> (struct vc_datas->vc_screenbuffer) only;
Very simple to implement in the fbdev itself: just replace the drawing ops by
dummy drawing ops.
This can already be done now, by providing a dummy struct display_switch, and
in the future by providing dummy accels.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X