Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
>Is it possible that "jump scroll" would provide more performance benefit >than an accelerated driver anyway? I wouldn't rule it out. If someone wants to wipe up some code I would have no problem testing it to see if it is worth it. >Seeing as you bring up this topic of writing a 9525 driver. It seems to >me rather wasteful that you (collectively linux framebuffer authors), >XFree86 and Berlin are all writing drivers for the same, hugely diverse >class of hardware, to support more or less the same ops on the hardware. > >Isn't possible to pool the development effort of video drivers? Doesn't >X require basically the same set of operations as the kernel? I.e., >initialise the card and video mode (usually the very complex part); do >some rendering ops (usually fairly simple). Sure, X provides a few more >kinds of rendering op, but that part of the code is usually much simpler >and smaller than the initialisation code. Well the goal of each is very much different. Fbcon was developed to deal the fact that most modern video hardware doesn't support text but graphical based modes instead. VGA text is slowly going away. Since are goal is to emulate a text console we just have to provide basic support to provide just this. We need to 1) Draw basic text -> Glyph operations. 2) scrolling -> hardware panning or a copy area operation. 3) scroll a region of the screen -> copy area operation. 4) Clear the display or region of display -> fillrect 5) Set color palette. 6) Manage a hardware cursor. 7) Manage the current resolution for VC switching or a mode change vi VT_RESIZE or TIOCSWINSZ. So fbcon is out of necessite. Now X you mean XFree86 which is really a OS in itself. Its goal to do everything itself so it can run everywhere know to mankind. As for Berlin I don't know the code so I can't say. As people are finding out XFree86 doing everything itself is having issues. A good example is the classic problem of X dying and you have to reboot the machine. Also when under heavy load and you exit X to the console you don't get the text mode. Well right now its tough luck and just reboot your machine. A M$ solution but people have been doing it so long they don't mind it. I hope to fix those problems for 2.5.X. As you can see I think the OS should handle the transfer from console mode to text mode and vice versa. Now for programming the accel engine to do graphics in userland. Well their is nothing wrong that each does their own thing. What does matter is their is a GIU independent kernel manager of the graphics engine state. DRI attempts to handle 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Basic Text Mode (was: Re: Question about SysRq)
> One more property, that i'd like to have should be request key to force > the most basic text mode (say 80x25) on the console, when eg. X freezes > and i kill its session, then last gfx mode resides on the screen and > see no way to restore back the text mode - /usr/bin/reset or something > alike will not do it. But it seems to be not a good idea at all, does it > ? I'm working on this. In theory it should be possible with SAK. Alt-SysRq-k resets the console. Here it set the vc_mode back to KD_TEXT and the keyboard back to VC_XLATE. It even reset ths palette. What it doesn't do is reset the hardware state. I hope to change this for 2.5.X. It is possible using fbdev to do this very easily. I'm working on it so you can go back and forth between fbdev and vgacon for those who want to if their hardware supports it use vgacon. This can be applied to this problem very easily. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: [lkml]Re: Matrox G400 Dualhead
> > >If I use X on an accelerated, normal Matrox screen, my monitor complains > > >on exit: > > > > > >fH 49.4 KHz, fV 39.8 Hz > > > > > >(and it doesn't sync at 40 Hz vertical refresh :-( ). > > > > > >This is _half_ of the normal 80 Hz. Using fbset -a "1600x1200-80" > > >before X, of after X, doesn't do anything. Does anybody know what to > > >hack out in X to get it to _not_ reset my G400 to some unusable > > >state? 3.3.6 was didn't do this. I can use the framebuffer-screen > > >just fine, but I miss the DGA extension. > > > >Try adding this to your XF86Config file: > > > >Section "Device" > >... > >Option UseFBDev > >... > >EndSection > > >A very neat trick. X can now be ended correctly. Unfortunately, any >scrolling on any VT afterwards gives me a corrupted screen - parts of >the screen from other VT's are inserted below, or over the cursor >position, and at 'half-line' intervals. In typing this email, I've seen >it 5 times already. >I'm willing to test anything - but the corruption is alway gone after I >switch VT's. So getting a screendump is not easy. I never have seen this problem before. Petr do you know what it could be? 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]
>>> As long as you are copying in real memory. So the PCI bus or the host bridge >>> implementation may be the actual limit. >> >> The CyrixIII sits on the same host bridges as the intel processors > >I don't know if it applies to this case but one thing I have seen make >a noticeable difference is whether or not write-combining is enabled. >If we have only be enabling MTRR's for intel this could do account >for it. I think what Geert was trying to point out is does MTRR perform was well with normal memory over bus to video memory transfers as compared to normal memory to normal memory transfers. MTTRs might not be optimzed for these kinds of transfers. I honestly can't say since I haven't tried it. I brought the MMX book home from works so I'm going to be experimenting with it this weekend to find out. I really like to compare the MMX performance to the word aligned transfers over the bus I have going. I had a bug in my soft accel code that prevented word alignment. Once I fixed that bug I seen a 10 fold improvement in rendering on the framebuffer. I'm not kidding about that improvement either :-) MTTRs enabled always makes a difference. I liek to try it with and without. I will do some benchmarkings. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More about 2.4.3 timer problems
>Err, tried the patch you recommended me to apply to the 2.4.3 source code >(not the 2.4.3-pre6), but everything else started complaining it couldn't >see printk() any more. Any advice? Thanks... Can you tell us your hardware configuration and your kernel configuration. What do you mean it couldn't see printk any more? 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "linux" terminal type
>> Is there any documentation on ths linux console terminal type? If >> so, where? > >Maybe cryptic but the most complete documentation of the linux terminal >and it's relatives are probably /etc/termcap and the ncurses terminfo >database. Aside of the code itself. Also take a look at http://www.vt100.net . Since linux tries to emulate the Dec vt100 at this site you will find the vt100 manuals. They are quite good and the esc codes are well described in them. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Underscore in rivafb
linux/Documentation/VGA-softcursor.txt 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How can I add a function to the kernel initialization
Is this a HD44780 LCD? Geert wrote a console driver sometime ago for this. He had a driver for it. If he still doesn't I have a copy of the code. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: [PATCH] matroxfb and mga XF4 driver coexistence...
>Agreed. The only thing I was thinking, was if the kernel is doing the >right thing now, it shouldn't be forced to work around a bug in XFree. >By not "fixing" the kernel, the XFree team would be forced to do the >right thing. Ha Ha Ha. That is funny. Okay it does get fixed many many months later. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3
> [One of the things for 2.5 is 15- or 31-bit keycodes. > The 7-bits we have today do no longer suffice. I have a 132-key keyboard.] Or for 2.5.X you could use EVIOCGKEYCODE or EVIOCSKEYCODE using /dev/eventX. Also the input api supports up to 220 different keys and could support up to 255. If you app needs to use a large keycode space then use this instead. Its better to use this interface especially for embedded systems that have only a serial console, but sometimes we need to use a regular keyboard. Consider for example a hand held iPAQ. Usually their is no keyboard attached. Here you have a graphical interface (using framebuffer) and a touch screen. So here I like to have a kernel that uses fbdev without the VT console system and input drivers to interface with the device. Debugging can be done by the serial console. If I attach a keyboard I like to be able to use it without having to have a console system needing to be built in. Remember every byte of space counts. Getting keycode via the console layer should eventually be replaced by this approach. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't use printk in linux 2.4.2 module
Try the following patch to linux/kernel/Makefile. If it works fine let me know and we can get it into the standard tree. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net --- Makefile.orig Sun Apr 15 10:06:40 2001 +++ MakefileSun Apr 15 10:06:51 2001 @@ -9,7 +9,7 @@ O_TARGET := kernel.o -export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o +export-objs = signal.o sys.o kmod.o context.o ksyms.o pm.o printk.o obj-y = sched.o dma.o fork.o exec_domain.o panic.o printk.o \ module.o exit.o itimer.o info.o time.o softirq.o resource.o \ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3
>> Yes, but they could be. Changing the Linux keycodes is a major >> break with compatibility. If the Linux keycodes are to be changed, >> then they ought to be become something that would allow XFree86 >> to become keyboard-independent. Why invent yet another encoding? > >You dont need to break compatibility. We have cooked, raw, semi-raw type >modes for keyboard right now. We just need to add semi-raw-extended and >raw-extended Why? X was designed with the idea of a input device core. Keyboards and mice are just a extenstion of this. Now that linux has a universal input api (/dev/input/eventX) we can wrapper X around this. I'm working on this for embedded devices. It just plain stupid to have VT support on something like a hand held iPAQ which doesn't usually have a keyboard attached. Also having fbcon built in for these devices just takes up valuable space since without a keybaord it pretty much is a waste. I rather have fbdev by itself with input support with only serial console support. Yes several X apps expect keybaord input coming in. Well we just don't support those apps on a handheld device. X apps that can work completely with a mouse would work perfectly on these embedded devices and would be installed. Since X has this nice clean design I really like to see XFree86 also use this approach. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3
>> this for embedded devices. It just plain stupid to have VT support on >> something like a hand held iPAQ which doesn't usually have a keyboard >> attached. Also having fbcon built in for these devices just takes up > >It makes plenty of sence to have support for virtual terminals on the >ipaq. I agree you want it modular so you can load the vt support when you >need it. Only if you have the attachable keyboard. Other embedded devices completely lack a keyboard. They do however have some graphical output. If you want X on them then using the /dev/input/event interface is the way to go. I like to see that for the desktop as well :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ANNOUNCE New Open Source X server
The Linux GFX project grew out the need for a higher performance X server that has a much faster developement cycle. In the last few years the graphics card and multimedia environments have grow at such a rate the current X solutions can no longer keep pace nor do they focus on producing high performance X servers specifically for linux. Also the community has demanded for specific functionality which has never come to light. This project looks to start from scratch to develope a new X enviroment that addresses these issues. I posted here because we will addressing several issues about hardware management between the kernel and the X window enevironment. Of course the X enrvironment is extremly broad so this will require skills from several areas as well as many programmers. So we welcome anyone how would like to see a alternative to the current X implemenation. If you like to subscribe to our mailing list just follow the link below. Thank you. http://lists.sourceforge.net/lists/listinfo/linuxgfx-dev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE New Open Source X server
Thank you. It is true all I want to do is help the community. I feel as alot of people do XFree86 can not meet the needs of the community. It is very sad that people feel that no amount of people in the open source community can make code of the same or better quality as XFree86 in a shorter period of time. I don't feel this way. Now I'm off to work on code and documentation for the project. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
>I was wondering why video drivers are not part of the kernel like every >other piece of hardware. I would think if video drivers were part of the >kernel and had a nice API for X or any other windowing system, would not >only improve performance but would allow competing windowing systems >without having to develop drivers for each. Has anyone thought or >rejected this idea. Hi! Their are two schools of though which I have encountered. One is have everything in userland. The second is have everything in the kernel. Well both are wrong. What is really needed? Proper virtualization of the graphics engine. This means the graphics hardware state is private to each process and no other process can effect another process graphics hardware state. This is all that is needed. DRI attemptes to address this. Will their be more kernel support in the future. Yes if you every want to port high end graphic servers. Here you end up dealing with with pipes on different nodes in NUMA systems. Data is passed from node to node to allow really fast parallel rendering. Note even in this case you don't have the hardware programmed in the driver but only management of the pipe state per process. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
>(Aside, is this because X uses keyboard in raw mode? would be nice to >still be able to ctrl-alt-del to rebood from console) Anyone know about >using alt-sysrq to restore console? > >So, if the kernel had a card specific module that just knew enough >to put the card back into text mode, or if it used the card's bios >to do it like the int10.a module in XFree 4.0, we would lack for nothing. >(hmm vesafb could be extended?) Working on it. I already have it so you can go from vgacon to /dev/fb and back to vgacon. It is in the works to have vgacon restore the text mode, palette and fonts when switching away from the X server. One of the problems I have seen is under heavy load switching away from X often doesn't restore the text console properly. Vgacon could. This is also handy when the X server dies :-) As for using the card's BIOS. Yuck yuck!! We have other platforms to consider like PPC. PPC is a pretty popular platform. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree864.0.2)
X server problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree86
>I believe you, although... why doesn't it happen with 2.2.17? vconsole >buffers in a different place in memory, I suppose? Vgacon has pretty much not changed. As for going from graphics mode and back it is quite complex and the X server handles all of it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
console spin_lock
Some time ago a intel i810 framebuffer driver was written. It only worked
for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
console system. Sooner or later we are going to run into the situtation
where we will have graphics hardware which has no vga core and wih be
purely DMA/irq based (i.e i810). In this case using the current
console_lock will block the driver itself. I have thought about a
possible solution. A semaphore can't be used since their is a spin_lock
in the console_softirq. Since this is in a interrupt context a
semaphore can't be used. Another idea was to do a
void get_vc_lock(void)
{
while (test_and_set_bit(0, &vc_var))
;
}
Any better ideas?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
> heh. > > I'm actually planning on grabbing console_lock and thoroughly strangling > it Ha Ha!! > - Use a semaphore for serialisation. I think this would be the best solution as well. > - For printk in interrupt context, grab the > semaphore (yes, you can do this). Don't forget about the idle task also. How is this done? By reintializing the semaphore. > - If it couldn't be acquired from interrupt context, > buffer the text in the log buffer and return. The text will be > printed by whoever holds the semaphore before they > drop it. By you saying couldn't be acquired from interrupt context do you mean from a process context or do you mean it failed to aquire it while in the interrupt context? > - Special "system booting" mode which bypasses all this > stuff. This wouldn't be to hard to do for VTs using the fact that keybaords are not initialized right away. As for serial consoles well that is another story. Of course we could have this flag set/cleared in start_kernel. > - Special "oops in progress" mode which just > punches through everything. You already developed the framework for this. > - Get rid of the special printk buffer - share the > log buffer. (Implies writes to console > devices will be broken into two writes when they > wrap around). > - Teach vsprintf to print into a circular buffer > (snprintf thus comes for free). > - Get rid of all the printk deadlock opportunities (fourth > attempt). Good luck. > - Get rid of console_tasklet. Do it in process context callback > or just do it synchronously. What about multidesktop systems? I have vgacon and mdacon working fine along each other. Each one has their own tasklet to allow them to work independent of each other. Meaning no race condition when both VC switch at the same time. > Assumption: > - Once the system is up and running, it's always safe to > call down() when in_interrupt() returns false - probably > not the case in parts of the exit path - tough. Don't forget the idle_task case as well. exit path? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: console spin_lock
> This statement of mine was grade-A bollocks. printk cannot of > course call down(). It needs to use __down_trylock and buffer > it up if it fails. (faster, too!) Okay. I'm going to start working on this tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Odd Question: pc_keyb as a module?
> I have a need to use pc_keyb as a module. I am using off the shelf ps/2 > keyboard chipsets as chording keyboard controllers. This uses a modified > pc_keyb.c that see's multiple key presses and translates them into > scancodes that are then handled by the rest of the keyboard driver. > > It would make life much better if I were able to have one pc_keyb.o module > that was the kernel original and another that has the chording code. That > way I could swap them, and I wouldn't need to rebuild and install an > entirely kernel everytime I make a tweak to the chording code. > > I'm not entirely sure home much trouble this would cause. But any help or > direction would be much appreciated. Hi! Actually we have something like that in our developement tree. We have converted over the PS/2 chipset and their devices to the Input API. The drivers are completely modular. With a USB keybaord this would be really handy. If have more questions just ask. Take a look at http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status/TODO page (test11-pre3)
> >8. Fix Exists But Isnt Merged
> > * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
> > (Keith Owens)
>
> Fix (by whom?)
Me :-)
> included in 2.4.0-test11-pre3. Looks good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: who's maintaning vgacon.c ?
> or in any way responsible for it? > James Simmons maybe ? I do some console work but mostly for 2.5.X. Their is no offical maintainer for this sub system as of now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] vgacon
> I've checked that and it works both on 2.2 and 2.4 but another test won't > hurt :-) No problems here :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] some cleanup in vgacon.c
> this is a newer cleaning patch for vgacon.c against test11. > It includes the one I sent a couple of days ago.Could you check this too > and if OK send it to Linus?Unless of course it violates the code-freeze > policy :-) The changes look fine except I have to question the *_scroll_enable changes. Could someone with a ia64 box with SoftSDV similator please test this patch? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: XFree 4.0.1/NVIDIA 0.9-5/2.4.0-testX/11 woes [solved]
> I've never seen such thing as code without bugs. In my experience, > the NVIDIA drivers are by far the most complete and solid 3D drivers > under Linux. I have to agree. Opensource or not the NVIDIA drivers are the best I have seen as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: XFree 4.0 problems.
> Ok I don't have the system in question, but i use others' experience with > the problem. The system is 2xPentium II Celeron 600 Mhz, 256 MB RAM, Video > Card Matrox Millenium G400, HDD 15 Gb Maxtor 7200 rpm, 2 Mb Cashe, > MB Abit BP6. > Both with kernel version 2.2.17 and 2.4.0-test11 after switching from > X to the console the system hangs, nothing changes if the console is frame > buffer or vt. If for X is used XFree 3.3.3.6 then the problem doesn't > appear. > Any help is apreciated, I don't really know if the problem is with the > kernel or with the config, so any directions will be a lot helpfull. > > Thanks in advance. Do you DRI turned on. IF so turn it off. Your problems will go away then. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] vgacon
On Fri, 17 Nov 2000 [EMAIL PROTECTED] wrote: > > Hi James, > > here is a patch for vgacon.c could you please check it? Okay. Thank for for posting it not as a attachment. > 1) removes explicit 0 initialisation of statics Those are fine. I already have in the ruby tree for the linux console project. > 2) removes an apparently unnecesary line in vgacon_scroll: > as I see it scr_end is computed anyway after the if statement so > no need to put it on the else branch. Hum. Never noticed that one. I will try this part out just to make sure their is no problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Screen corruption on startup 2.4.0-test7
On Sat, 2 Sep 2000, David Benfell wrote: > Hello all, > > I've seen this with earlier versions, starting on my old laptop, a > Compaq Presario 1250. But I'm now in the interesting position that my > only access to the machine is via ssh. This is what I saw when I > booted: > > U > LILO boot: > Loading 2.4.0-test7.. > Uncompr g L.L Ok, booting the k#ke > > The "U" is actually a flashing green U. And the hash mark is really a > musical note character. It finished booting, but with no further > display, and I can still see the above. There is no visible response > to the keyboard. What video driver are you using? Fbcon or vgacon? If Fbcon which fbdev driver in particular? 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Screen corruption on startup 2.4.0-test7
> > What video driver are you using? Fbcon or vgacon? If Fbcon which fbdev > > driver in particular? > > > This would be vgacon, having never figured out if it's even possible > to get framebuffers working on the machine. > > Also, the normal power-saving/screen-saving function of blanking the > screen is not working. Vgacon !!! Have you tried putting that video card in another machine and testing the same kernel? Trust me. When I was a sys admin the first thing we did was swap hardware into another machine to see if it was a hardware problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple Keyboards in 2.2/2.4?
> Is it / will it be possible to run multiple, or at least two keyboards > before the new linux console code in 2.5? XFree86 can use multiple keybaords. I don't think XF4.0 still supports USB keyboards. Give them another 6 months or a year. By then they should support them. As for the console system not it can't use multiple keybaords. You can use multiple keybaords via the /dev/event interface. > What we would like to do is to run multiple user sessions off a single > machine. Using either Dualhead graphics cards, or simply using two > graphics cards, the display is not a problem (although console support > would be nice we only really need X), and multiple mice is not a problem > with either two USB mice or one USB and one PS/2. However, there does not > seem to be a way to address a second keyboard seperately at the moment. > Looking at the linux console project the multi-head code "ruby" seems to > be aimed at 2.5. I was wondering if there is any chance of being able to > address keyboards before then? > > Nick > > Ie. Given that displays and mice almost work, we think it would be really > cool to have two people work from a single box. AFAIK keyboard is the only > issue stopping this... It is a whole lot more complex than that. Its possible with XF4.0 but only with very limited hardware. The reason for it being on the console level is so the kernel can manage the resources between different applications. Consider a multihead enviroment with 2 users. Each VT is in console mode. One starts the X server. Automatically X wants to set each video card into graphics mode. Now if I was say writing code on that second VT and all the sudden X started I would be really upset. Now consider a "good" X server (not XFree86) that starts and doesn't affect me. What happens when I start a X server on my VT? What impact will it have on the other user. This things have to be considered. On the console level their are complex issues as well. Consider a system with 4 VTs attached to one machine. What if one person pressed Ctrl-Alt-Del. Anyone can bring the system down when multiple people depend on it. This is bad. I could go on with other issues but will not bore you with them. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple Keyboards in 2.2/2.4?
> Points taken. Given that I withdraw the need for console support and / or > used two seperate video cards, does it make it more feasible? IMNSHO X servers should move as far away from dependency on /dev/ttyX as it can do. The X server should use /dev/event, /dev/fb, and /dev/drm. You can't totally move away because we will have to deal with VC switching. In this case lock VT switching. When a key combo is pressed while in X that tells it it should VT switch then save any needed data like what is in the framebuffer and close all devices (/dev/event, /dev/dri, and /dev/fb). In multihead enviroment it is going to get very very difficult to use /dev/tty0. Piping multiple keyboards threw /dev/tty0 isn't going to work. Believe I have tried it. The idea of /dev/tty0 as a foreground console should go away once linux really supports multihead. Their are tricks to find out what VC you are on and then open the local tty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple Keyboards in 2.2/2.4?
> Im using 2.2.18pre with XFree 4.0 , AGP, DRM and a USB keyboard and mouse. > It all works. One keyboard not multiple tho. > > They dont seem to support the automatic change of keyboard mapping with the > USB events though I see they use their own drives and don't use the /dev/event interface :-( You can't multiplex multiple keyboards threw /dev/tty0. Sad thing is the user losses out. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple Keyboards in 2.2/2.4?
On Fri, 8 Sep 2000, Adam Sampson wrote: > On Thu, Sep 07, 2000 at 10:00:05AM -0400, James Simmons wrote: > > On the console level their are complex issues as well. Consider a > > system with 4 VTs attached to one machine. What if one person pressed > > Ctrl-Alt-Del. Anyone can bring the system down when multiple people depend > > on it. > > That particular one is a userspace issue; you can simply tell init not to do > anything when Ctrl-Alt-Del is pressed. (You'd also want to disable > magic-sysrq for the same reason.) Don't forget about where printk goes to. Should it goe to every VT or just one? As for SysRq do users want the option to disable for everyone, have it work for one VT or allow it for everyone? Do we want a all or nothing policy? 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: printer problems and more on Re: Screen corruption on startup2.4.0-test7
> > This would be vgacon, having never figured out if it's even possible > > to get framebuffers working on the machine. > > > > Also, the normal power-saving/screen-saving function of blanking the > > screen is not working. > > > Hello, > > More information from /var/log/messages (this is a short extract): > > Sep 3 19:09:28 kindling mingetty[10251]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10257]: /dev/tty3: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10250]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10249]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10266]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10268]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10264]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10262]: /dev/tty3: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10260]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10276]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10274]: /dev/tty3: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10270]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10272]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10278]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10286]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10284]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10282]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10280]: /dev/tty3: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10294]: /dev/tty3: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10290]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10296]: /dev/tty3: cannot open tty: > No such device > Sep 3 19:09:28 kindling init: Id "3" respawning too fast: disabled > for 5 minutes > Sep 3 19:09:28 kindling mingetty[10292]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10288]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10302]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10304]: /dev/tty6: cannot open tty: > No such device > Sep 3 19:09:28 kindling init: Id "6" respawning too fast: disabled > for 5 minutes > Sep 3 19:09:28 kindling mingetty[10300]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10306]: /dev/tty4: cannot open tty: > No such device > Sep 3 19:09:28 kindling init: Id "4" respawning too fast: disabled > for 5 minutes > Sep 3 19:09:28 kindling mingetty[10298]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10308]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling mingetty[10310]: /dev/tty5: cannot open tty: > No such device > Sep 3 19:09:28 kindling init: Id "5" respawning too fast: disabled > for 5 minutes Yipes!! I have seen this happen when /etc/inittab is messed up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Screen corruption on startup 2.4.0-test7
> Note that this problem has only appeared after rebooting from a 2.3.x > or 2.4.0-testx kernel without a full power down. As long as I never > bring up a newer kernel AND do a shutdown -r, I don't have this > problem. Sounds like the BIOS cleaned up after vgacon. > too alarmed. Basically, it came down to noting that it's difficult to > move a video card from a laptop and that the problem seemed to have > gone away after I rebooted to 2.2.16 (though I recall now seeing some > corruption while it was booting, but nothing like the full-scale > lockout I had with 2.4.0-test7) -- the keyboard was usable under > 2.2.16. Okay, I didn't realize you had a laptop. Does anyone else have this laptop and reported the same problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple Keyboards in 2.2/2.4?
> > Don't forget about where printk goes to. Should it goe to every VT or just > > one? As for SysRq do users want the option to disable for everyone, have > > it work for one VT or allow it for everyone? Do we want a all or nothing > > policy? > > It is actually very easy. Just one keyboard, and just one monitor is > "system console". All others are just normal terminals. > > There's already same problem with serial console / vt problem. There's > solution saying "user selects using command line what _real_ console > is". No new problem here. > > [And yes, serial console can do both sysrq and printing kernel > messages. No new problems here.] Yes I know serial console works just as well as video console. I came up with the idea of a "system console" as well. I just wanted to see if people seen this also a "good" solution. This _real_ console is the one where you can do things like ctrl_alt_del from it where other VTs you can't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Console
> My name is Kirti Desai. I am trying to write a new
> console driver.
No problem. What are you looking to do?
> * Is console related to a tty_driver?
A tty is a posix terminals which cover alot of different types of
hardware. Everything from modems to serial consoles to video terminals
which use hardware like VGA video cards. If you are talking about
video consoles (VTs) then they are a subset of ttys types. Remember their
are many types of ttys.
> We have two functions register_console and register_tty_driver? How are
> these two related?
As for register_console you are talking about the system console.
This is the console where things like kernel errors printed via printk
go. Note any kind of tty can be a system console.
> In tty_init(tty_io.c) we register dev_tty_driver and
> dev_syscons_driver?
> In console_init(tty_io.c) con_init(tty_io.c for
> CONFIG_VT=y) is
> called. It registers console_driver and calls
> register_console(vt_console_driver).
This is registering a video terminal (VT) as a system console. Thus
printks will be sent to this terminal.
> * To do printk we need not open the /dev/console file?
Printk is handled inside the kernel. Take a look at linux/kernel/printk.c.
What do you mean by open? Via userland ?
> What I found was
> start_kernel(init/main.c) calls console_init and
> kernel_thread(init..)
> which calls init is called later which opens
> /dev/console.
Right. First we initalize the the basic termios structure and startup up
hardware that can be started early. Later on other types of hardware which
depend on other subsystems running such as the PCI bus are called in
tty_init. Next /dev/console is opened. I believe this is the first opened
file in a linux system thus its file descriptor is 0. It is stdin. With
dup we set stdin, stdout, and stderr all equal to each other.
if (open("/dev/console", O_RDWR, 0) < 0)
printk("Warning: unable to open an initial console.\n");
(void) dup(0);
(void) dup(0);
Then init is started after the kernel is done. It is the father of all
process. It uses the file /etc/inittab to setup all your consoles.
> * How are stdin/stdout/stderr mapped to the tty's?
See above.
> What want to know
> if that when we call say printf in user
> program,finally write(1,..) gets called which calls
> tty_write ,con_write. How does tty come in
> picture?
printf sends by default data to stdout whcih goes to /dev/console threw
the tty layer to con_write if it is VT.
> * What are /dev/console /dev/tty0, /dev/tty1 files?
/dev/console is the system console (where the printk go). /dev/tty
represents the current console for the current process. If I'm on a serial
console and do a echo "hi" > /dev/tty it will print out on the screen. If
I'm using a console run by fbcon it will do the same thing. Now /dev/tty0
represents the current foreground video console. If you do a echo to
/dev/tty0 it will be printed on the current video display. /dev/tty1 and
so on represent the virtaul consoles for VTs. Those are the consoles you
switch to when you press Alt-F[1-6].
> Any pointer to documentation ..would be of great
> help?
Not alot. This is a linux console project which just started. See the
address in my sig.
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 [[EMAIL PROTECTED]] /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Any dual AGP slot motherboards?
Hi! I looking for a motherboard that supports more than one AGP slot. Does anyone know any like this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any dual AGP slot motherboards?
> There is no reason there cannot be multiple AGP buses. After all there are > motherboards with 2,3,4 (or more!) PCI buses. Apple sells a computer with dual AGP slots. I just was looking for a intel box like this. Since AGP is a port on the PCI bus it is possible to have more than one AGP port on a/each PCI bus but this requires the PCI chipset to support this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] small mdacon fix.
Mdacon in test10-pre4 missed one restore_flag. Here is the patch that removes it. --- mdacon.c.orig Thu Oct 19 20:17:07 2000 +++ mdacon.cThu Oct 19 20:17:20 2000 @@ -129,7 +129,6 @@ outb_p(reg+1, mda_index_port); outb_p(val & 0xff, mda_value_port); spin_unlock_irqrestore(&mda_lock, flags); - restore_flags(flags); } static int test_mda_b(unsigned char val, unsigned char reg) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any dual AGP slot motherboards?
> > ** Reply to message from James Simmons <[EMAIL PROTECTED]> on Thu, 19 Oct 2000 > > 18:34:51 -0700 (PDT) > > > Apple sells a computer with dual AGP slots. > > I've never heard this. Could you tell me exactly which model this is? > > I think he's confusing dualhead cards with dual agp slots. > > I dont think *anyone* makes dual agp slots. After much searching I couldn't find one. It was one of those mac rumors people spread around. I still like to get more than one AGP going. If I have multiple PCI bus in theory I should be able to have one AGP port on each PCI bus. Right? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre5 -- Compile error drivers/video/video.o: In function`vesafb_set_disp': undefined references
> I am experimenting with compiling lots of stuff as modules. > I hit what is either a user error, a configuration script > bug or a symbol export bug. I just tried your setup and it worked for me. Try a make mrproper and then a make dep etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spinlock fix for vgacon
Hi!
Please test this patch for fixing the SMP deadlock issues Keith Owens
was talking about. As for my other vgacon work. Well that needs alot more
time. These deadlock issues are really important and need to be
fixed. Thank you.
--- vgacon.c.orig Tue Oct 24 18:45:58 2000
+++ vgacon.cTue Oct 24 19:08:51 2000
@@ -46,11 +46,13 @@
#include
#include
#include
+#include
#include
#include
#include
+static spinlock_t vga_lock = SPIN_LOCK_UNLOCKED;
#define BLANK 0x0020
@@ -152,8 +154,7 @@
* ddprintk might set the console position from interrupt
* handlers, thus the write has to be IRQ-atomic.
*/
- save_flags(flags);
- cli();
+ spin_lock_irqsave(&vga_lock, flags);
#ifndef SLOW_VGA
v1 = reg + (val & 0xff00);
@@ -166,7 +167,7 @@
outb_p(reg+1, vga_video_port_reg);
outb_p(val & 0xff, vga_video_port_val);
#endif
- restore_flags(flags);
+ spin_unlock_irqrestore(&vga_lock, flags);
}
static const char __init *vgacon_startup(void)
@@ -415,7 +416,7 @@
if ((from == lastfrom) && (to == lastto)) return;
lastfrom = from; lastto = to;
- save_flags(flags); cli();
+ spin_lock_irqsave(&vga_lock, flags);
outb_p(0x0a, vga_video_port_reg); /* Cursor start */
curs = inb_p(vga_video_port_val);
outb_p(0x0b, vga_video_port_reg); /* Cursor end */
@@ -428,7 +429,7 @@
outb_p(curs, vga_video_port_val);
outb_p(0x0b, vga_video_port_reg); /* Cursor end */
outb_p(cure, vga_video_port_val);
- restore_flags(flags);
+ spin_unlock_irqrestore(&vga_lock, flags);
}
static void vgacon_cursor(struct vc_data *c, int mode)
@@ -533,11 +534,11 @@
{
/* save original values of VGA controller registers */
if(!vga_vesa_blanked) {
- cli();
+ spin_lock_irq(&vga_lock);
vga_state.SeqCtrlIndex = inb_p(seq_port_reg);
vga_state.CrtCtrlIndex = inb_p(vga_video_port_reg);
vga_state.CrtMiscIO = inb_p(video_misc_rd);
- sti();
+ spin_unlock_irq(&vga_lock);
outb_p(0x00,vga_video_port_reg);/* HorizontalTotal */
vga_state.HorizontalTotal = inb_p(vga_video_port_val);
@@ -561,7 +562,7 @@
/* assure that video is enabled */
/* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
- cli();
+ spin_lock_irq(&vga_lock);
outb_p(0x01,seq_port_reg);
outb_p(vga_state.ClockingMode | 0x20,seq_port_val);
@@ -598,13 +599,13 @@
/* restore both index registers */
outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
- sti();
+ spin_unlock_irq(&vga_lock);
}
static void vga_vesa_unblank(void)
{
/* restore original values of VGA controller registers */
- cli();
+ spin_lock_irq(&vga_lock);
outb_p(vga_state.CrtMiscIO,video_misc_wr);
outb_p(0x00,vga_video_port_reg);/* HorizontalTotal */
@@ -629,7 +630,7 @@
/* restore index/control registers */
outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
- sti();
+ spin_unlock_irq(&vga_lock);
}
static void vga_pal_blank(void)
@@ -750,7 +751,7 @@
charmap += 4*cmapsz;
#endif
- cli();
+ spin_lock_irq(&vga_lock);
outb_p( 0x00, seq_port_reg ); /* First, the sequencer */
outb_p( 0x01, seq_port_val ); /* Synchronous reset */
outb_p( 0x02, seq_port_reg );
@@ -766,7 +767,7 @@
outb_p( 0x00, gr_port_val );/* disable odd-even addressing */
outb_p( 0x06, gr_port_reg );
outb_p( 0x00, gr_port_val );/* map start at A000: */
- sti();
+ spin_unlock_irq(&vga_lock);
if (arg) {
if (set)
@@ -793,7 +794,7 @@
}
}
- cli();
+ spin_lock_irq(&vga_lock);
outb_p( 0x00, seq_port_reg ); /* First, the sequencer */
outb_p( 0x01, seq_port_val ); /* Synchronous reset */
outb_p( 0x02, seq_port_reg );
@@ -833,8 +834,7 @@
inb_p( video_port_status );
outb_p ( 0x20, attrib_port );
}
- sti();
-
+ spin_unlock_irq(&vga_lock);
return 0;
}
@@ -865,12 +865,12 @@
registers; they are write-only on EGA, but it appears that they
are all don't care bits on EGA, so I guess it doesn't matter. */
- cli();
+ spin_lock_irq(&vga_lock);
outb_p( 0x07, vga_video_port_reg ); /* CRTC overflow register */
ovr = inb_p(vga_video_port_val);
outb_p( 0x09, vga_video_port_reg ); /* Font size register */
fsr = inb_p(vga_video_port_val);
- sti();
+ spin_lock_irq(&vga_lock)
Re: test10-pre5 -- Compile error drivers/video/video.o: In function`vesafb_set_disp': undefined references
> I had this option in my .config: > > CONFIG_FB_RIVA=m > > Changing that option to: > > # CONFIG_FB_RIVA is not set > > made the errors stop occuring. I am not sure > why building the Riva support as a module would > cause the errors to be generated. Did this. No problem. The only difference was I did a make dep;make bzImage;make modules etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Linux-2.4.0-test10
> I have a similar hardware list and I don't observe any of these problems on > 2.4.0-test10x. Is it possibly a hardware conflict somewhere? > > What I do see occasionally is if X was ever heavy on the memory usage (say > I've run GIMP for a couple of hours) then the text console's font set gets > trashed until the next reboot. Console driver failing to reset something? No! The X server resets the VGA mode including resetting the fonts. See xc/programs/Xserver/hw/xfree86/vgahw to see how XF4.0 switchs between X and vgacon. It see under heavy pressure X fails to reset the video hardware on it own :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Broken colors on console with 2.4.0-textXX
> Console colors are completely messed up (read: black, I even suspect > the font to be corrupt somehow) if switching back to console mode > from X (either by quitting or ctrl-alt-fX) in recent 2.4.0-textXX > kernels. 2.2.XX do work just fine. Is this a known problem with a > known fix? How recent of a test kernel. Yes their was a problem with the console palette but it is now fixed in the most recent test kernels. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Several concurrent terminals.
> We'd like to have two sets of keyboard/mouse/screen connected to the > same computer with each set having the control and output of an > independent X > session each, concurrently. There might for instance be the ps/2 > keyboard and mouse and > USB dittos. After attempting (and failing) we believe the problem is > really one of the kernel only allowing one virtual terminal to be active > at one time. Is this so and what can be done? Yes it is :-( I'm actually working on this problem. See http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vesafb doesn't work in 240t10?
> What fb driver would support it? I seen a i810 fbdev driver before but I haven't see any updates to it in a awhile. > does vga16 support 1024x768? No. vga16 supports standard vga graphics modes (ie 640x480 16 colors). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
> * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
>(Keith Owens)
Still not fixed :-( Here is the patch again. Keith give it a try and tell
me if it solves your problems.
--- vgacon.c.orig Tue Oct 24 18:45:58 2000
+++ vgacon.cTue Oct 24 19:08:51 2000
@@ -46,11 +46,13 @@
#include
#include
#include
+#include
#include
#include
#include
+static spinlock_t vga_lock = SPIN_LOCK_UNLOCKED;
#define BLANK 0x0020
@@ -152,8 +154,7 @@
* ddprintk might set the console position from interrupt
* handlers, thus the write has to be IRQ-atomic.
*/
- save_flags(flags);
- cli();
+ spin_lock_irqsave(&vga_lock, flags);
#ifndef SLOW_VGA
v1 = reg + (val & 0xff00);
@@ -166,7 +167,7 @@
outb_p(reg+1, vga_video_port_reg);
outb_p(val & 0xff, vga_video_port_val);
#endif
- restore_flags(flags);
+ spin_unlock_irqrestore(&vga_lock, flags);
}
static const char __init *vgacon_startup(void)
@@ -415,7 +416,7 @@
if ((from == lastfrom) && (to == lastto)) return;
lastfrom = from; lastto = to;
- save_flags(flags); cli();
+ spin_lock_irqsave(&vga_lock, flags);
outb_p(0x0a, vga_video_port_reg); /* Cursor start */
curs = inb_p(vga_video_port_val);
outb_p(0x0b, vga_video_port_reg); /* Cursor end */
@@ -428,7 +429,7 @@
outb_p(curs, vga_video_port_val);
outb_p(0x0b, vga_video_port_reg); /* Cursor end */
outb_p(cure, vga_video_port_val);
- restore_flags(flags);
+ spin_unlock_irqrestore(&vga_lock, flags);
}
static void vgacon_cursor(struct vc_data *c, int mode)
@@ -533,11 +534,11 @@
{
/* save original values of VGA controller registers */
if(!vga_vesa_blanked) {
- cli();
+ spin_lock_irq(&vga_lock);
vga_state.SeqCtrlIndex = inb_p(seq_port_reg);
vga_state.CrtCtrlIndex = inb_p(vga_video_port_reg);
vga_state.CrtMiscIO = inb_p(video_misc_rd);
- sti();
+ spin_unlock_irq(&vga_lock);
outb_p(0x00,vga_video_port_reg);/* HorizontalTotal */
vga_state.HorizontalTotal = inb_p(vga_video_port_val);
@@ -561,7 +562,7 @@
/* assure that video is enabled */
/* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
- cli();
+ spin_lock_irq(&vga_lock);
outb_p(0x01,seq_port_reg);
outb_p(vga_state.ClockingMode | 0x20,seq_port_val);
@@ -598,13 +599,13 @@
/* restore both index registers */
outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
- sti();
+ spin_unlock_irq(&vga_lock);
}
static void vga_vesa_unblank(void)
{
/* restore original values of VGA controller registers */
- cli();
+ spin_lock_irq(&vga_lock);
outb_p(vga_state.CrtMiscIO,video_misc_wr);
outb_p(0x00,vga_video_port_reg);/* HorizontalTotal */
@@ -629,7 +630,7 @@
/* restore index/control registers */
outb_p(vga_state.SeqCtrlIndex,seq_port_reg);
outb_p(vga_state.CrtCtrlIndex,vga_video_port_reg);
- sti();
+ spin_unlock_irq(&vga_lock);
}
static void vga_pal_blank(void)
@@ -750,7 +751,7 @@
charmap += 4*cmapsz;
#endif
- cli();
+ spin_lock_irq(&vga_lock);
outb_p( 0x00, seq_port_reg ); /* First, the sequencer */
outb_p( 0x01, seq_port_val ); /* Synchronous reset */
outb_p( 0x02, seq_port_reg );
@@ -766,7 +767,7 @@
outb_p( 0x00, gr_port_val );/* disable odd-even addressing */
outb_p( 0x06, gr_port_reg );
outb_p( 0x00, gr_port_val );/* map start at A000: */
- sti();
+ spin_unlock_irq(&vga_lock);
if (arg) {
if (set)
@@ -793,7 +794,7 @@
}
}
- cli();
+ spin_lock_irq(&vga_lock);
outb_p( 0x00, seq_port_reg ); /* First, the sequencer */
outb_p( 0x01, seq_port_val ); /* Synchronous reset */
outb_p( 0x02, seq_port_reg );
@@ -833,8 +834,7 @@
inb_p( video_port_status );
outb_p ( 0x20, attrib_port );
}
- sti();
-
+ spin_unlock_irq(&vga_lock);
return 0;
}
@@ -865,12 +865,12 @@
registers; they are write-only on EGA, but it appears that they
are all don't care bits on EGA, so I guess it doesn't matter. */
- cli();
+ spin_lock_irq(&vga_lock);
outb_p( 0x07, vga_video_port_reg ); /* CRTC overflow register */
ovr = inb_p(vga_video_port_val);
outb_p( 0x09, vga_video_port_reg ); /* Font size register */
fsr = inb_p(vga_video_port_val);
- sti();
+ spin_lock_irq(&vga_lock);
vde = maxscan & 0xf
Re: Broken colors on console with 2.4.0-textXX
> > How recent of a test kernel. Yes their was a problem with the console > > palette but it is now fixed in the most recent test kernels. > > 2.4.0-test10-pre5 Please upgrade to a newer kernel. This problem has been fixed :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Broken colors on console with 2.4.0-textXX
> > > > How recent of a test kernel. Yes their was a problem with the console > > > > palette but it is now fixed in the most recent test kernels. > > > > > > 2.4.0-test10-pre5 > > > > Please upgrade to a newer kernel. This problem has been fixed :-) > > > > Unfortunately I cannot confirm this. Checked 2.4.0-test10 and the problem > is still there. I digged further and it seems to be a race condition(?) > triggered by swapped out stuff - because just starting X and switching > back to the console works fine, but as I start some memory-consuming stuff > (I have only 32Megs of ram) and then switch back to the console its > completely garbagled the first time and black the second time and later. I have seen this problem before. The problem is the X server is the one that sets the hardware back to vga text mode. Under heavy stress the X server can fail and the hardware is left in a undeterminate state. I have started on working to solve this problem but it will be something for 2.5.X since it requires quite a bit of change to vgacon and the console system. My recent vga patches where early attempts at this but they are still incomplete. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Broken colors on console with 2.4.0-textXX
> Umm, so why does this not happen with 2.2.X at all? Also the system is > not really stressed, but I simply do startx, inside an xterm go to > some random source, make -j, wait till the compile is complete and then > switch back to the console - its just that it seems that swapped out > X server or console stuff causes this. > > I consider this quite a showstopper for 2.4.0. Actually I just thought about it. Do you DRI running. When you have DRI enabled you shouldn't VT switch. It is a design flaw in DRI and the console system :-(. Disable DRI you you will be fine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Broken colors on console with 2.4.0-textXX
> You didnt read the config, etc. I posted - I dont have DRI - I > have an old P100 with 32Megs of ram and an old ATI Mach64 graphics > card. There really is nothing unusual with my setup - console > garbagling is even without loading the bttv module at all. Okay. So it is what I thought it was orginally. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Broken colors on console with 2.4.0-textXX
> Okay - so its the console subsystem that gets it wrong? Remember > that 2.2.X gets it right - with the same X server. I really > would like to have this fixed in 2.4 - can I do something to > help fixing this? (I'm not familiar with the console subsystem, > neither with the X server) It is the way it is done that is wrong. At present the X server is in total control of setting the console system back to text mode. This works under normal conditions but when the system is stressed or X fails you are stuck. The console system should be setting the video hardware back to vga text mode instead of the X server. I have been working on a patch that does that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Broken colors on console with 2.4.0-textXX
> Sure - but this was always the case. And using 2.2 with the same > (or more) stress the Xserver is still able to set the video hardware > back to vga text mode. I just want to know whats the difference > between 2.2 and 2.4 that causes failure in 2.4. I don't think it is the console system. I bet if you stress 2.2 even more you will get the same results. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Network error
Something I seen on a lug. Anyone have a patch for this? I'm trying to compile a 2.2.17 kernel. When I do a make bzImage, I get this error. It seems to be centering on networking areas (nfs, svclock, tcp, etc.) tcp_input.c:1393:52: warning: pasting would not give a valid preprocessing token tcp_input.c:1441:85: warning: pasting would not give a valid preprocessing token - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SysRq behavior
> Hi! > > > I don't remember having the same problem months (6?) ago when > > I built my first Kernel with this enabled (well, maybe I never > > touched the key). > > > > When built into the Kernel, by only pressing the > > PrintScreen/SysRq the current application is terminated (tested > > on a console and GNU screen). Is this just me or I should > > expect it? > > Probably bug. Happens for me, too, and it is pretty nasty. Just played with this bug. It doesn't kill a login shell but does any app running on it. I just went looking for where "Quit" is printed out. When I press SysRq Quit is printed on the command line. Any ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.X PPC/atyfb patch
The previous patch for 2.2.X for 2.4.0-testX.
--- atyfb.c.origMon Dec 11 14:38:11 2000
+++ atyfb.c Mon Dec 11 14:35:03 2000
@@ -3621,7 +3621,7 @@
}
#endif
if (default_vmode == VMODE_CHOOSE) {
- if (Gx == LG_CHIP_ID || Gx == LI_CHIP_ID)
+ if (Gx == LG_CHIP_ID || Gx == LI_CHIP_ID || Gx == LP_CHIP_ID)
/* G3 PowerBook with 1024x768 LCD */
default_vmode = VMODE_1024_768_60;
else if (machine_is_compatible("iMac"))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.X patches for fbcon
This patch allows you select different modes on a Mac. The functionality
was there but not taken advantage of. This is needed because the resolution
can be 834x628 on a Mac and the screen is really screwed up with more than
8 bit in that case.
--- fbmem.c.origMon Dec 11 14:18:44 2000
+++ fbmem.c Mon Dec 11 14:19:08 2000
@@ -92,6 +92,8 @@
extern void hpfb_setup(char *options, int *ints);
extern void sbusfb_init(void);
extern void sbusfb_setup(char *options, int *ints);
+extern void platinum_init(void);
+extern void platinum_setup(char *options, int *ints);
extern void valkyriefb_init(void);
extern void valkyriefb_setup(char *options, int *ints);
extern void control_init(void);
@@ -183,6 +185,9 @@
#ifdef CONFIG_FB_HP300
{ "hpfb", hpfb_init, hpfb_setup },
#endif
+#ifdef CONFIG_FB_PLATINUM
+{ "platinumfb", platinum_init, platinum_setup },
+#endif
#ifdef CONFIG_FB_VALKYRIE
{ "valkyriefb", valkyriefb_init, valkyriefb_setup },
#endif
--
This patch forces 1024x768-60 modes on PowerBook Lombard and
Mainstreet. No need to pass vmode:14 anymore.
--- atyfb.c Mon Dec 11 14:28:19 2000
+++ atyfb.c.origWed Oct 4 22:22:28 2000
@@ -2796,7 +2796,7 @@
* works on iMacs as well as the G3 powerbooks. - paulus
*/
if (default_vmode == VMODE_CHOOSE) {
- if ((Gx == LG_CHIP_ID)||(Gx == LI_CHIP_ID)||(Gx == LP_CHIP_ID))
+ if (Gx == LG_CHIP_ID)
/* G3 PowerBook with 1024x768 LCD */
default_vmode = VMODE_1024_768_60;
else if (Gx == LN_CHIP_ID)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 vs Inspiron
> There was some discusion lately re: Dell Inspiron FB probs. The bad news > is the ATI Mach64 display support is still broken but just selecting > VESA VGA graphics console is working fine. > > The patient is a Dell Inspiron I7500 1050x1450 display, vga = 794. Ah the infamous Rage Mobility chipset. Three versions of the same chipset but each is very different. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bsd-style cursor
> included a patch against 2.4.0-test9 (should apply against latest but > haven't checked) which adds the config option to have a bsd-style cursor > in VT's by default. I was hoping it might be considered for inclusion so > that I don't have to patch it in myself every time :-) How about placing echo '\033[?17;120c' In one of your startup scripts. This will give you this nice BSD cursor you like. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TIOCGDEV ioctl
> Hi Linus, Alan,
>
> some applications do need to know where the console (/dev/console)
> actually maps to. For processes with a controlling terminal, you may see
> it in /proc/$$/stat. However, daemons are supposed to run detached (they
> don't want to get killed by ^C) and some processes like init or bootlogd
> do still need to be able to find out.
>
> The kernel provides this information -- sort of:
> It contains the TIOCTTYGSTRUCT syscall which returns a struct. Of course,
> it changes between different kernel archs and revisions, so using it is
> an ugly hack. Grab for TIOCTTYGSTRUCT_HACK in the bootlogd.c file of the
> sysvinit sources. Shudder!
>
> Having a new ioctl, just returning the device no is a much cleaner solution,
> IMHO. So, I created the TIOCGDEV, which Miquel suggests in his sysvinit
> sources. It makes querying the actual console device as easy as
> int tty; ioctl (0, TIOCGDEV, &tty);
>
> Patches against 2.2.18 and 2.4.0-testX are attached.
> Please apply.
Based on fgconsole.c. I just threw it together in a few minutes.
/*
* consolewhat.c - Prints which VC /dev/console is.
*/
#include
#include
int
main(){
struct vt_stat vtstat;
int fd;
fd = open("/dev/console", O_RDONLY);
if (fd < 0 && errno == EACCES)
fd = open("/dev/console", O_WRONLY);
if (fd < 0)
return -1;
if (ioctl(fd, VT_GETSTATE, &vtstat)) {
perror("consolewhat: VT_GETSTATE");
exit(1);
}
printf("%d\n", vtstat.v_active);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: TIOCGDEV ioctl
> You're confusing /dev/console and /dev/tty0. /dev/console might be > associated with /dev/ttyS0 or /dev/lp1 Oops. Forgot about serial consoles :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[linux-fbdev] Re: [PATCH] console palette fix
Here is patch to fix console palettes for the 2.2.X kernels. Its against
2.2.17.
--- console.c.orig Wed Oct 4 22:23:34 2000
+++ console.c Wed Oct 4 22:28:50 2000
@@ -575,10 +575,13 @@
}
if (redraw) {
+ int update;
+
set_origin(currcons);
+ update = sw->con_switch(vc_cons[currcons].d);
set_palette(currcons);
- if (sw->con_switch(vc_cons[currcons].d) && vcmode != KD_GRAPHICS)
- /* Update the screen contents */
+ if (update && vcmode != KD_GRAPHICS)
+ /* Update the screen contents */
do_update_region(currcons, origin, screenbuf_size/2);
}
set_cursor(currcons);
Re: [PATCH] console palette fix
> I've seen the problem on both of my computers with Creative Riva TNT2. On > this card the palette turns darker. On other cards the palette turns to > rubbish or corrupted in another fashionable ways. It's a bug in those > cards - switching to video mode and back to text mode doesn't preserve the > text mode palette so the OS must restore it by itself. Now looking closer to the XFree86 code your right. It is buggy hardware. XFree86 X servers do attempt to reset the VGA palette themselves for all cards. It is basic code and should work on all video cards. > about this problem exactly. Read the console.c of 2.4 - Linus already > patched it this way (your patch and then my patch), so I suggest we do the > same in 2.2. Agree. Alan please patch 2.2.X with both are patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Why 2 cli in vga_vesa_blank?
Hi! While working on vgacon I noticed their are 2 cli() in vga_vesa_blank that are excuted one after another. Is their are a reason for this or shoudl it be just one cli()? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[linux-fbdev] Re: Why 2 cli in vga_vesa_blank?
> > While working on vgacon I noticed their are 2 cli() in vga_vesa_blank
> > that are excuted one after another. Is their are a reason for this or
> > shoudl it be just one cli()?
>
> If you look at vgacon.c you still see remains of what the code used to
> look like. Now comapare with vga16fb.c and it is clear what happened.
After I sent the message I see what was bothering me. Actually the code in
vgacon is correct and their is a bug in vga16fb with its own version of
vga_vesa_blank. I was actually looking at vga16fb instead of vgacon. My
mistake especially since both codes are som much alike. In vga_vesa_blank
in vga16fb you have:
cli();
Seq...
Crt...
/* save orginal ...
if (!info->vesa_blanked) {
...
cli();
Where it should be as in vgacon.c:
vga_vesa_blank(..)
{
if (!info->vesa_blanked) {
cli();
Seq...
Crt...
sti();
}
test [PATCH] new vgacon and vga16fb
Hi! This patch places code common to both vgacon and vga16fb into a common file (vga.c). The utlimate goal is to have the ability to go from vgacon to fbcon and back. At present you can't do this. This will allow for easier debugging in the future for fbdev drivers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/usb/Config.in
This patch fixes a minor config error for drivers/usb/Config.in. When you select USB Human Interface Device (HID) support I assume you should be able to select a USB mouse and/or USB keyboard. With the current Config.in you can't. --- Config.in.orig Tue Oct 10 00:10:06 2000 +++ Config.in Tue Oct 10 00:10:27 2000 @@ -80,7 +80,7 @@ comment ' Input core support is needed for USB HID' else dep_tristate ' USB Human Interface Device (HID) support' CONFIG_USB_HID $CONFIG_USB $CONFIG_INPUT - if [ "$CONFIG_USB_HID" != "y" ]; then + if [ "$CONFIG_USB_HID" = "y" ]; then dep_tristate ' USB HIDBP Keyboard support' CONFIG_USB_KBD $CONFIG_USB $CONFIG_INPUT dep_tristate ' USB HIDBP Mouse support' CONFIG_USB_MOUSE $CONFIG_USB $CONFIG_INPUT fi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test [PATCH] new vgacon and vga16fb Part II
Oops. Sorry folks. My patch was too big to be posted on the mailing list. Uncompressed it is 63K. Here it is compressed. >Hi! > > This patch places code common to both vgacon and vga16fb into a common >file (vga.c). The utlimate goal is to have the ability to go from vgacon >to fbcon and back. At present you can't do this. This will allow for >easier debugging in the future for fbdev drivers. newvga.diff.gz
RE: [PATCH] drivers/usb/Config.in
> Not needed. This is a misunderstanding. Maybe that needs > some work (in Help maybe), but not this patch. Yes please. It can be very misleading. > Then if you select USB HID support, that builds the hid driver, > which handles mice, keyboards, joysticks, gamepads, speaker > buttons, any-old-kind-of buttons, toaster buttons, etc. I didn't realize USB had this level of functionality. > OTOH, if you want just some basic USB mouse & keyboard support, > you don't have to use the hid driver, you can use the HIDBP > (HID Boot Protocol) drivers instead. However, these drivers > (hid and hidbp) are mutually exclusive and you shouldn't > try to select both of them. Okay I see. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/usb/Config.in
> > I didn't realize USB had this level of functionality. > > Hrm... I wonder if anyone out there is making USB Toasters That would > be really nice -- have a nice snack waiting for me when I get home, etc. ;) I remember someone made a /dev/coffee to control their coffe machine. Do a search on the web for the Coffee-HOWTO. I'm not kidding. So I can see someone easily making a toaster driver. ALso a toaster would be perfect for the input suite. It sort of like a one button mouse. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 + Winchip2/2A processor family == hang on boot
Either you forgot to attach the patch for it was bigger than 40K. On Tue, 10 Oct 2000, Frank de Lange wrote: > Dave, > > This patch fixed the problems, for now. The system now boots OK, and seems to > run OK (have not hit it very hard yet since it currently runs without a > heatsink). Tnanks... > > Cheers//Frank > -- > W ___ > ## o o\/ Frank de Lange \ > }# \| / \ > ##---# _/ \ > \ +31-320-252965/ >\[EMAIL PROTECTED]/ > - > [ Hacker: http://www.jargon.org/html/entry/hacker.html ] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] Re: test [PATCH] new vgacon and vga16fb Part II
> And I suggest this addition (cfr. the other fbcon-*.c since 2.4.0-test5-pre5): Done. I have alot more big changes coming :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] linux article with kernel references
> >The article isn't that wrong, that several people get paid now for hacking > >doesn't change much. It's more about proper software engineering, some > >people call it "a matter of taste" and are born with it, but for other > >people it's a hard learning process. > > The opinion piece is also (probably) about non-kernel software. It is > hard to tell because he gives no examples at all. It was not > pursuasive to me. I've seen terrible code on every system from IBM > mainframes to Mac. That is not news. His grep seems to be two things. Poor software design. This does not only afflict linux but pretty much everyone. The power behind opensource is when someone comes around with a better design they can show it to the world. Then it can be incorporated. We all know linux is not a perfect OS. In fact we should never think this. The day we do is the day we stop moving forward. The second grep is the delay we see. Well M$ also suffers from this problem as well as others. I think the root of this problem is each version of kernel is a massive change. Instead of a bunch of new kernels with smaller changes a massive redesign is done. Doing it this way is much harder since new bugs that where not there before show up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3dfx voodoo5 framebuffer patch...(w/actual patch this time)
Take at look at Attila's changes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: vgaconsole driver SMP safe fix against linux-2.4.0-test9
> James has just posted a big patch against this code, so you should > coordinate this with him. > > One point: you should have included linux/spinlock.h rather than > asm/spinlock.h. Obviously someone is already including this file, so > you can simply remove the #include altogether. I already added his changes and I'm testing them. More massive changes have occured. I hope to have teh ability to go from vgacon to fbcon and back to vgacon by the end of this week. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/usb/Config.in
> James, > > Please let me know if the attached patch helps to clarify this > any (or enough). I tried adding a line between HID and HIDBP > support options, but that didn't work out, so it's not there. Much better. Since the average joe will not look at Config.in but instead read the help this will make sense. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mdacon using spinlocks
The problems with vgacon with cli made me go and add spinlocks to mdacon
as well to prevent nasty lock ups. Give it a try. Against a test-9
kernel. Here you go:
--- mdacon.c.orig Wed Oct 11 18:09:01 2000
+++ mdacon.cWed Oct 11 18:14:18 2000
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
+static spinlock_t mda_lock = SPIN_LOCK_UNLOCKED;
/* description of the hardware layout */
@@ -80,7 +82,6 @@
MODULE_PARM(mda_last_vc, "1-255i");
#endif
-
/* MDA register values
*/
@@ -110,23 +111,24 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port);
outb_p(val, mda_value_port);
- restore_flags(flags);
+ spin_unlock_irqrestore(&mda_lock, flags);
}
static void write_mda_w(unsigned int val, unsigned char reg)
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port); outb_p(val >> 8, mda_value_port);
outb_p(reg+1, mda_index_port); outb_p(val & 0xff, mda_value_port);
+ spin_unlock_irqrestore(&mda_lock, flags);
restore_flags(flags);
}
@@ -134,15 +136,14 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port);
outb (val, mda_value_port);
udelay(20); val = (inb_p(mda_value_port) == val);
- restore_flags(flags);
-
+ spin_unlock_irqrestore(&mda_lock, flags);
return val;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: new 3dfx framebuffer driver released
I have done some work on the 3dfx as well recently. I like to work with you to move it toward the new fbcon api. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] update to vgacon/vga16fb work
Hi! Here is a update to my work that I posted earlier. The new vga.c file contains common vga routines. Both share a common struct that contains the hardware state. TODO: Merge font handling code. Font code is broken in vga16fb for text modes. Attempting to make a universal function for both. Have vgacon set its own video mode in vgacon_startup. This allows for vgacon to take over the console system again. newvga.diff.gz
Re: IRQ affinity vs. MTRRs, was Re: 36 bit MTRRs, Re: test10-pre1problems on 4-way SuperServer8050
> > every CPU to avoid slowdowns. So that if you set that eth0's > > IRQ will be handled by CPU1, the MTRRs of CPU1 will be set > > accordingly, and the other CPUs will not care about eth0, > > so they do not need eth0's MTRR settings. > > A little question. Why do we want to bind irq of eth0 to a single CPU ? > imho it will casue slowdown of some situation. Why don't we leave scheduler > to select CPU for processing IRQ ? This would be really horrible for video cards. X would come to a crawl :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] s3 support for vesafb
We really need real S3 framebuffer devices that work across many platforms. > It's port of patch from http://www.colonel-panic.com (for kernel 2.2.12) > to 2.4.0-test10-pre1. It's quite useful if you have older s3 video card > (i.e. Virge) without VBE 2.0, but it's rather tricky so it is not in main > tree. > > URL: http://republika.pl/bkz/240t10p1-s3lfb.diff (7kB) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[linux-fbdev] [PATCH] updated vgacon/vga16fb work
Hi! Here is more updated work on the vgacon to fbcon to vgacon again code. I almost got it. I just need to figure out how to free up the resources from the fbdev drivers I tried it out on. I have attemped on the G400 matrox driver and the vga16 driver. Both give a : Device or resource busy when I go to rrmod it. newvga.diff.gz
[linux-fbdev] Re: 2.4.0test9 VESA kernel config options not available
> for some reason, xconfig is not giving me the chance to select the kernel > options i found in the 2.2.13 kernel .config: Did you select Prompt for development and/or incomplete code/drivers under Code maturity level options? You need to select this to select framebuffer devices. Also make sure your card is actually VESA 2.0 compliant.
[linux-fbdev] [PATCH] mdacon SMP fix
ANyone with a MDA card on a SMP or even UP machione please test this
patch. This patch should fix any SMP deadlocks that could happen with
a MDA card. Thank you.
--- mdacon.c.orig Wed Oct 11 18:09:01 2000
+++ mdacon.cWed Oct 11 18:14:18 2000
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
+static spinlock_t mda_lock = SPIN_LOCK_UNLOCKED;
/* description of the hardware layout */
@@ -80,7 +82,6 @@
MODULE_PARM(mda_last_vc, "1-255i");
#endif
-
/* MDA register values
*/
@@ -110,23 +111,24 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port);
outb_p(val, mda_value_port);
- restore_flags(flags);
+ spin_unlock_irqrestore(&mda_lock, flags);
}
static void write_mda_w(unsigned int val, unsigned char reg)
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port); outb_p(val >> 8, mda_value_port);
outb_p(reg+1, mda_index_port); outb_p(val & 0xff, mda_value_port);
+ spin_unlock_irqrestore(&mda_lock, flags);
restore_flags(flags);
}
@@ -134,15 +136,14 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port);
outb (val, mda_value_port);
udelay(20); val = (inb_p(mda_value_port) == val);
- restore_flags(flags);
-
+ spin_unlock_irqrestore(&mda_lock, flags);
return val;
}
Re: [linux-fbdev] [PATCH] mdacon SMP fix
> I will test this soon, hopefully. I move tomorrow, and will be bringing my > X environment and my audio environment into my dual P200 machine. This is > against which kernel? 2.4.0-test10 prepatch, or? 2.4.0-test9. It should work against a test10-preX. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] mdacon SMP fix
> Hi James,
>
> I think you missed to remove one restore_flags().
> (There could be more, I only looked shortly at your patch)
Yeap. I didn't remove the restore_flag calls. Fixed now. Here is the
correct patch. I tested to see if it compiles against a test-9 kernel.
It does. That is the problem with fixing code that you don't have the
hardware for. You can't find those stupid mistakes before you post a
possible patch :-( It is next to impossible to find a MDA card. *shameless
plug *
--- mdacon.c.orig Wed Oct 11 18:09:01 2000
+++ mdacon.cMon Oct 16 23:03:26 2000
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
+static spinlock_t mda_lock = SPIN_LOCK_UNLOCKED;
/* description of the hardware layout */
@@ -80,7 +82,6 @@
MODULE_PARM(mda_last_vc, "1-255i");
#endif
-
/* MDA register values
*/
@@ -110,39 +111,38 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port);
outb_p(val, mda_value_port);
- restore_flags(flags);
+ spin_unlock_irqrestore(&mda_lock, flags);
}
static void write_mda_w(unsigned int val, unsigned char reg)
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port); outb_p(val >> 8, mda_value_port);
outb_p(reg+1, mda_index_port); outb_p(val & 0xff, mda_value_port);
- restore_flags(flags);
+ spin_unlock_irqrestore(&mda_lock, flags);
}
static int test_mda_b(unsigned char val, unsigned char reg)
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(&mda_lock, flags);
outb_p(reg, mda_index_port);
outb (val, mda_value_port);
udelay(20); val = (inb_p(mda_value_port) == val);
- restore_flags(flags);
-
+ spin_unlock_irqrestore(&mda_lock, flags);
return val;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re:Escape sequences & console
I would say the escape sequence are for /dev/ttyX since only Vt emulate Dec VT 100s. The web site to look for this info is http://www.vt100.net 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:IMS Twin Turbo 128 framebuffer
>Is there any particular reason why imsttfb isn't available in the >i386 arch? > >It doesn't work in X either in spite of being "supported", but >that's not for this list. I had this card while working at suse and I did try to get it to work on ix86. The problem is the card is initialzed by its firmware which is forth since this is a Apple card. As for getting the detail specs to get it to work on ix86 (making it firmware independent) good luck. You will have to suck the info from the deeps pits of apple. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
>} The fbdev console problem is too horrible to pretend to solve by resyncing >} on timer interrupts. At least for the x86 the fix is to sort out the fb >} locking properly > >How close is that? Working on it. I have done alot of cleanup to the fbdev layer. I have moved to a xxxfb_fillrect, xxxfb_copyarea, xxxfb_imageblit to handle all the console functions. I have written really fast software versions of these functions for cards that lack this functionality. A exmaple. My software fillrect function is nearly as fast as the Voodoo 3 at 1024x768 at 32 bpp. You can think of my functions as really fast or the accelerator really slow. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Keyboard simulation
>Take a look at vojtech's new input suite. Someone else is also working on a brallie reader using the input suite. We have a new keyboard vt driver that uses the input suite. Event packets come in and it is sent to the right terminals. I hope to have all the keyboard drivers converted over by 2.5.0. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nvidia fb 0.9.0
>Is this a known problem? Are there work-arounds? Yes. The problem is caused by the fbdev driver using 8 bit width for its RAMDAC and the X server uses 6 bits. Try teh UseFBDev option for the X server. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fbdev cursor management
>Guys, > >I've been taking a look at the cursor flashing code, >from the point of view of how it's affected by the >recent enabling of interrupts across the console code. I see the problems. I just pursposed a new cursor api soe we can have a clean fbdev to fbcon abstraction. Also we really need to move the curent cursor code in fbcon.c:fbcon_startup. They really belong in their respected drivers. >It all happens in timer handlers and interrupt handlers, >with no protection against mainline code accessing the >hardware simultaneously. Many drivers use spinlocks to manage access. >- Collapse all the various per-driver cursor flashing > routines into a single place - manage the timer from > drivers/video/fbcon.c and from there, call into the > driver layer if requested. fbcon_cursor :-) > The only way we have of doing this at present is to call > schedule_task() from within the timer handler. This works > fine, but it complicates the device close and module unload > problem somewhat. del_timer_sync + flush_scheduled_tasks > will be needed in the right places. Yuck!!! I see this also a problem for VBL dependent drivers. Some drivers to require you sync with the VBL to do things like change the color map. Worst some of these drivers require you poll a bit to see if the VBL occured. [snip] rivafb problems. These will be fixed now they are pointed out. 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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
>>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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
>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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
>>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 [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
