linuxconsole-dev

Re:Q: sun serial keyboard on x86 system?

[James S. <jsi...@li...>]

>Is there something special that i miss? Do i have to create any special
>devices in /dev/... ?

All input devices can be accessed threw /dev/input/eventX. Take a look at
dmesg. You should see all your /dev/eventX devices registered. Do this
after you run inputattach. For example I have a serial mouse. I do a
inputattach -ms /dev/ttyS1. Then reading dmesg I see a message similar to:

input3: Serial Mouse on serio0
event3: Event device for input3

Now you know everything is working :-) Now to test it ...

>How to debug the whole process? Is evtest usefull for that - or does it
>primarly deal with joystick devices / mice?

.. with evtest. Every input device, keyboard, mouse, touchscreen etc has a
/dev/input/eventX associated with it. Just run evtest on the proper
/dev/input/eventX and you will see it work. Test it with that device. For
2.4.X the events of the keyboard should to to the console. With this
versus all keyboard events go to the console system. In the CVS tree we
have. The keyboards are attached to a specific VT. If you make 3 keyboards
and 3 video cards they will all behave as a seperate terminal independent
of each other. Data from one keybaord will not end up on another
workstation.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Q: sun serial keyboard on x86 system?

[Ralf A. <ra...@KO...>]

Hello,

i try using a serial sun5 keyboard on an x86 system.
I've used the adapter described at the "Linux Input Project" site - and
can see characters arriving on keypress / release when using e.g. minicom
on the serial port the keyboard is attached to.

Unfortunately i fail to get the keyboard itself working
I'm using Linux 2.4.1.
I do an
	insmod .../serial.o
	insmod .../serio.o
	insmod .../serport.o

	inputattach -skb /dev/ttyS0 &

	insmod .../input.o
	insmod .../evdev.o
	insmod .../keybdev.o

but apart from an entry
	Mar 27 23:01:16 dell kernel: serio0: Serial port tts/0
in /var/log/messages i don't get any further reaction.

Is there something special that i miss? Do i have to create any special
devices in /dev/... ?
How to debug the whole process? Is evtest usefull for that - or does it
primarly deal with joystick devices / mice?

Any hints will be highly appreciated - i'm just doing a version of an
PS/2-to-serial adapter for attaching PS/2 (chording) keyboards (like the
Handykey Twiddler2 http://www.handykey.com) to a Compaq iPAQ PDA running
Linux - but testing / developing with the serial Sun5 keyboard on an x86
system makes development much easier.

Best regards
 ralf

Re: vgacon on which card?

[Matan Ziv-Av <ma...@sv...>]

On Tue, 27 Mar 2001, James Simmons wrote:

> 
> Say you have several PCI graphics cards in a system but only have vgacon
> running. Is their away to determine which PCI card vgacon is running on?

The enabled one :-)

I don't see a general solution.
You can know if an AGP card's vga portion is enabled by checking the
corresponding bit in the pci bridge configuration space. But for PCI
cards there is no standard way of enabling vga.
If you have only one card with I/O enabled you can know this is the
card. If you have more, you can write to the 0xb8000 region, and see in
what linear aperture the write happens.



-- 
Matan Ziv-Av.                         ma...@sv...

Which VT to boot with ?

[James S. <jsi...@li...>]

Hi!

   As you might of noticed I broke fbcon again. In order to debug it I
have to go and rework the code to allow mdacon to be my first VT and
system console to see what is going on. I really want to find a better
solution. What I need is to have it so that we can pick which boot console
we want, vgacon, mdacon, or fbcon. Also mda_console_init is called later.
We don't want it called later if we have vt_console_init intialize
mdacon. We also have to find away to deal with fbcon and what it does and
doesn't take over. If we have only one VT and it is dummy_con or vgacon
or end mdacon then fine fbcon can take over it. But what if we have more
than one fbdev device. Then we have to figure out which card vgacon is
running on. Same with a mda card and hgafb. Does anyone have any good
ideas?

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

vgacon on which card?

[James S. <jsi...@li...>]

Say you have several PCI graphics cards in a system but only have vgacon
running. Is their away to determine which PCI card vgacon is running on?


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

Thansk for the code. Now I go think. Ugh!

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>Ewww, that means that all possible video modes must be listed in a table
>in the kernel?

No. Of course we kind of do that now with modedb. It is the same as now.
The only difference is it goes threw the tty layer to the fbcon layer
instead of from userland to fbdev layer to tty layer. It makes for a
consistant interface for mode changing for all console drivers. It also
allows for a resize_vc function which in turn allows for a generic VC
switching function. No more con_switch is needed. The next benfiet is
since it is coming from the tty layer we have modes of columns*font width
by rows*font height. We don't need code to deal with case if the number of
columns is 80 and 1/2. Now if we are stuck with a system where the card
mode is set and can't be changed we then do the opposite and look for a
font set that makes the mode perfect. If we can't find one well its time
to provide a special font for that system.

>I'd prefer to keep the current situation because it is has the "policy"
>in user space, ie, the video programming information.

Hah? Policy is still in userspace. You just express the resolution in
columns and rows instead of pixels. You could express it in pixels as well
since struct winsize allows this. I haven't implemented it yet since it
also requires dealing with possible font handling. Yuck!

>That seems like a great step backwards to me.  For instance, how do you
>handle the case where you want to support:
>
>        FBCon Text, 80x30 @ 50Hz
>        FBCon Text, 80x30 @ 60Hz

With FB_ACTIVATE_NXTOPEN. The question you have to ask yourself is why do
you need this specifically if you are going to be using fbdev only as a
text console ? [below]

>We already fully support this on ARM machines since one of theapplications
>of ARM boxen are web-top devices, which are required to produce TV
>compatible signals.

Are you still using fbdev just as a text console here or are we talking
here a app that opens /dev/fb and uses /dev/fb. If that is the case then
the card is the only limit. If not and for some reason you need the
graphical console while needing to produce TV compatiable signals then you
can

a) Make the default fb_var_screeninfo compatible to produce TV signals in
   the driver.

b) Use modedb to select the mode you want.

c) Open /dev/fb but use the FB_ACTIVATE_NXTOPEN flag to preserve the
   hardware state to what you want when going back to fbcon.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[Benjamin H. <be...@ke...>]

>
>
>I need to ask you where is this code? I like to take a look at it to
>figure out what you are doing.

You can find the mach64 sleep notifier in atyfb.c (under
CONFIG_POWERBOOK) , the code
that calls sleep notifiers is in drivers/macintosh/via-pmu.c (the various
sleep functions).

The current mach64 & chipsfb notifiers don't do anything to fbcon (they don't
stop the cursor timer neither). I have some WIP progress code in my local
tree that
implements sleep support for more recent models with a notifier in
aty128fb too.
I added some fbcon suspend/resume routines for the cursor, but they are
currently
called from my aty128fb sleep notifier, which is wrong.

Ben.

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[Russell K. <rm...@ar...>]

James Simmons writes:
> Believe it not the functional allready exist in the tty layer to change
> a video mode for a specific tty. It just has never been implemented in
> linux. I have implemented it for my own kernel tree.
> ...
> The only thing is you can't change the depth using this approach. So what
> do we do? FB_ACTIVATE_NXTOPEN :-) This signals to fbdev to preserve the
> color depth for the console system. Once take_over_console is called it
> will reinitalize the color palette for us. As for setting all the VCs we
> have good old VT_RESIZE.

Ewww, that means that all possible video modes must be listed in a table
in the kernel?  I'd prefer to keep the current situation because it is
has the "policy" in user space, ie, the video programming information.

That seems like a great step backwards to me.  For instance, how do you
handle the case where you want to support:

	FBCon Text, 80x30 @ 50Hz
	FBCon Text, 80x30 @ 60Hz

We already fully support this on ARM machines since one of the applications
of ARM boxen are web-top devices, which are required to produce TV
compatible signals.

Note that I'm not talking about a specialised embedded driver here, but one
that is used for machines which will do 1280x1024 @ 75Hz down to standard
TV signals without modifications.  In fact, I'm using it at 1280x1024
right now. ;)

--
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>> This will be fixed for 2.5.X. I'm working on a solution now. IMNSHO the
>> kernel should manage switching from VGA text mode to some graphical
>> mode and visa versa. Same for fbcon. Opening /dev/fb should manage
>> shutdown the console system itself.

>Should it?  What happens if I run fbset to change the text resolution?
>When fbset opens /dev/fb, should the console really be shutdown?

Believe it not the functional allready exist in the tty layer to change
a video mode for a specific tty. It just has never been implemented in
linux. I have implemented it for my own kernel tree.

TIOCGWINSZ
TIOCSWINSZ

struct winsize {
        unsigned short ws_row;
        unsigned short ws_col;
        unsigned short ws_xpixel;
        unsigned short ws_ypixel;
};

The only thing is you can't change the depth using this approach. So what
do we do? FB_ACTIVATE_NXTOPEN :-) This signals to fbdev to preserve the
color depth for the console system. Once take_over_console is called it
will reinitalize the color palette for us. As for setting all the VCs we
have good old VT_RESIZE.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>I guess "support" routines can be provided by fbcon to switch to
>dummycon.

Hum. I had the idea of sharing the pm_dev between the console and fbdev.
When the console goes to shutdown it automatically affect the pm_dev in
fb_info for the fbdev driver. Vice versa is true. I have to think about it
more.

>it must of course not try to flash the cursor on an already sleeping
>fbdev (handled by the switch to dummycon I beleive if we decide to do it
>this way).

Yes. take_over_console would hide the old_cursor and replace with the
dummy_con cursor which doesn't exist.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>Ok, I see. Currently, the sleep process is started from an ioctl sent to
>another driver, which will in turn call various notifier functions to
>shut down bits of hardware and finally put the machine to sleep. It's not
>a direct ioctl to the /dev/fb (which may not be opened).

[snip]...

I need to ask you where is this code? I like to take a look at it to
figure out what you are doing.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>That's not the only fbdev bug in X.  I have been getting a lot of reports
>which indicate that FBDev X does not turn off text mode acceleration when
>it wants to switch into graphics mode.

This will be fixed for 2.5.X. I'm working on a solution now. IMNSHO the
kernel should manage switching from VGA text mode to some graphical mode
and visa versa. Same for fbcon. Opening /dev/fb should manage shutdown the
console system itself. One we can't count on XFree86 getting it right.
Second I have seen reports of when X fails under heavy load or some other
bizzare reason to properly reset the console itself. This leaves the
machine in a useless state and requires a reboot. I'm also working on
this.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

combine macserial.o and serial.o in one binary

[Olaf H. <ol...@su...>]

Hi,

I try to combine macserial.o and serial.o in one binary:
CONFIG_MAC_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y

I applied that patch to drivers/char/tty_io.c:
diff -urN linuxppc_2_4/drivers/char/tty_io.c linuxppc_2_4.serialconsole/drivers/char/tty_io.c
--- linuxppc_2_4/drivers/char/tty_io.c  Sat Feb 17 05:03:25 2001
+++ linuxppc_2_4.serialconsole/drivers/char/tty_io.c    Mon Mar 19
09:20:24 2001
@@ -2172,11 +2173,17 @@
 #ifdef CONFIG_SERIAL_CONSOLE
 #if (defined(CONFIG_8xx) || defined(CONFIG_8260))
        console_8xx_init();
-#elif defined(CONFIG_MAC_SERIAL)
-       mac_scc_console_init();
-#elif defined(CONFIG_SERIAL)
-       serial_console_init();
 #endif /* CONFIG_8xx */
+#if defined(CONFIG_MAC_SERIAL)
+       if (_machine == _MACH_Pmac)
+               mac_scc_console_init();
+#endif
+#if defined(CONFIG_SERIAL)
+#ifdef __powerpc__
+       if (_machine == _MACH_chrp || _machine == _MACH_prep)
+#endif
+               serial_console_init();
+#endif
 #ifdef CONFIG_SGI_SERIAL
        sgi_serial_console_init();
 #endif


That gives me a serial console output on a Pmac and on a IBM machine
with a PC style serial port. But the IBM machine can not open the
initial console:
Warning: unable to open an initial console.

My first thought was to rename the conflicting/duplicate function names
in macserial.c, I just added a mac_*. But that doesnt work at all.

Any ideas how to get this to work?



Gruss Olaf

-- 
 $ man clone

BUGS
       Main feature not yet implemented...

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[Russell K. <rm...@ar...>]

On Thu, Mar 15, 2001 at 01:03:35PM +0100, Geert Uytterhoeven wrote:
> On Thu, 15 Mar 2001, Benjamin Herrenschmidt wrote:
> > One problem I have is that my fbdev sleep routine will restore the mode
> > on wakeup,
> > but that of course doesn't work with X when not using useFBDev as fbdev
> > have no
> > knowledge of the current mode or register settings used by X.
> 
> That's a bug in X: one must not change the video mode by banging the hardware
> when running on a fbdev system.

That's not the only fbdev bug in X.  I have been getting a lot of reports
which indicate that FBDev X does not turn off text mode acceleration when
it wants to switch into graphics mode.

As far as I know, the Debian people looking after the ARM FBDev package
haven't produced a patch for XFree for this particular problem yet.
However, it'd be nice to get it fixed by some means.

--
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

(who doesn't run XFree86... yet... but his original port of plain old X11R6)

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[Geert U. <ge...@li...>]

On Thu, 15 Mar 2001, Benjamin Herrenschmidt wrote:
> One problem I have is that my fbdev sleep routine will restore the mode
> on wakeup,
> but that of course doesn't work with X when not using useFBDev as fbdev
> have no
> knowledge of the current mode or register settings used by X.

That's a bug in X: one must not change the video mode by banging the hardware
when running on a fbdev system.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[Benjamin H. <be...@ke...>]

>  Now for fbcon its simpler. Things get writing to the shadow buffer
>(vc_screenbuf). When the console gets woken up update_screen is called.
>While power down the shadow buffer can be written to which is much faster
>than saving a image of the framebuffer. Of course if you still want to do
>this such in the case of the X server then copy the image of the
>framebuffer to regular ram. Then power down /dev/fb using some ioctl calls
>provide.

Ok, I see. Currently, the sleep process is started from an ioctl sent to
another
driver, which will in turn call various notifier functions to shut down
bits of
hardware and finally put the machine to sleep. It's not a direct ioctl to
the /dev/fb (which may not be opened). 

One problem I have is that my fbdev sleep routine will restore the mode
on wakeup,
but that of course doesn't work with X when not using useFBDev as fbdev
have no
knowledge of the current mode or register settings used by X.

I'm wondering if it would be possible to make X think there's a console switch
(without actually switching to an active console, as we don't know if we
even have
one of those available for us), wait for it to reply, and then start the sleep
process.

One other possibility would be to implement APM-like events, I still have
to study
those more in details as our sleep process is currently quite different
from APM
(and definitely not BIOS-based).

For now, I have my hooks in fbcon that suspend/restart the cursor timer,
that's
enough to make sleep stable on 2.4 since we take care of shutting down
the display
very last (after any other driver) to make sure no printk will end up
trying to
display something while the chip is powered down.
I'll digest your various comments look into all this in more depth with
2.5 console
codebase. I beleive some solution must be found for x86 laptops too.

Ben.

[patch] console and bust_spinlocks() fixes

[Andrew M. <an...@uo...>]

Three things.

- Adds lib/bust_spinlocks.c for architectures which don't
  provide bust_spinlocks() .

- Closes a race between tioclinux() and console scrolling
  which was leaving bits of stuff on the screen when the
  mouse was used with gpm. 

- Added a missing break statement in do_syslog() (James Simmons) 


Patch against -ac20 is here.  The full `remove console_lock' patch
against 2.4.3-pre4 is at http://www.uow.edu.au/~andrewm/linux/console.html



--- linux-2.4.2-ac20/drivers/char/console.c	Tue Mar 13 20:29:21 2001
+++ ac/drivers/char/console.c	Tue Mar 13 21:12:47 2001
@@ -69,6 +69,9 @@
  *
  * Removed old-style timers, introduced console_timer, made timer
  * deletion SMP-safe.  17Jun00, Andrew Morton <an...@uo...>
+ *
+ * Removed console_lock, enabled interrupts across all console operations
+ * 13 March 2001, Andrew Morton
  */
 
 #include <linux/module.h>
@@ -1034,6 +1037,7 @@
 	color = def_color;
 }
 
+/* console_sem is held */
 static void csi_m(int currcons)
 {
 	int i;
@@ -1173,6 +1177,7 @@
 	return report_mouse;
 }
 
+/* console_sem is held */
 static void set_mode(int currcons, int on_off)
 {
 	int i;
@@ -1238,6 +1243,7 @@
 		}
 }
 
+/* console_sem is held */
 static void setterm_command(int currcons)
 {
 	switch(par[0]) {
@@ -1292,19 +1298,7 @@
 	}
 }
 
-static void insert_line(int currcons, unsigned int nr)
-{
-	scrdown(currcons,y,bottom,nr);
-	need_wrap = 0;
-}
-
-
-static void delete_line(int currcons, unsigned int nr)
-{
-	scrup(currcons,y,bottom,nr);
-	need_wrap = 0;
-}
-
+/* console_sem is held */
 static void csi_at(int currcons, unsigned int nr)
 {
 	if (nr > video_num_columns - x)
@@ -1314,15 +1308,18 @@
 	insert_char(currcons, nr);
 }
 
+/* console_sem is held */
 static void csi_L(int currcons, unsigned int nr)
 {
 	if (nr > video_num_lines - y)
 		nr = video_num_lines - y;
 	else if (!nr)
 		nr = 1;
-	insert_line(currcons, nr);
+	scrdown(currcons,y,bottom,nr);
+	need_wrap = 0;
 }
 
+/* console_sem is held */
 static void csi_P(int currcons, unsigned int nr)
 {
 	if (nr > video_num_columns - x)
@@ -1332,15 +1329,18 @@
 	delete_char(currcons, nr);
 }
 
+/* console_sem is held */
 static void csi_M(int currcons, unsigned int nr)
 {
 	if (nr > video_num_lines - y)
 		nr = video_num_lines - y;
 	else if (!nr)
 		nr=1;
-	delete_line(currcons, nr);
+	scrup(currcons,y,bottom,nr);
+	need_wrap = 0;
 }
 
+/* console_sem is held (except via vc_init->reset_terminal */
 static void save_cur(int currcons)
 {
 	saved_x		= x;
@@ -1355,6 +1355,7 @@
 	saved_G1	= G1_charset;
 }
 
+/* console_sem is held */
 static void restore_cur(int currcons)
 {
 	gotoxy(currcons,saved_x,saved_y);
@@ -1375,6 +1376,7 @@
 	EShash, ESsetG0, ESsetG1, ESpercent, ESignore, ESnonstd,
 	ESpalette };
 
+/* console_sem is held (except via vc_init()) */
 static void reset_terminal(int currcons, int do_clear)
 {
 	top		= 0;
@@ -1430,6 +1432,7 @@
 	    csi_J(currcons,2);
 }
 
+/* console_sem is held */
 static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int c)
 {
 	/*
@@ -1810,6 +1813,7 @@
 #define CON_BUF_SIZE	PAGE_SIZE
 DECLARE_MUTEX(con_buf_sem);
 
+/* acquires console_sem */
 static int do_con_write(struct tty_struct * tty, int from_user,
 			const unsigned char *buf, int count)
 {
@@ -2049,7 +2053,7 @@
 void set_console(int nr)
 {
 	want_console = nr;
-	schedule_task(&console_callback_tq);
+	schedule_console_callback();
 }
 
 #ifdef CONFIG_VT_CONSOLE
@@ -2171,9 +2175,21 @@
  *	Handling of Linux-specific VC ioctls
  */
 
+/*
+ * Generally a bit racy with respect to console_sem().
+ *
+ * There are some functions which don't need it.
+ *
+ * There are some functions which can sleep for arbitrary periods (paste_selection)
+ * but we don't need the lock there anyway.
+ *
+ * set_selection has locking, and definitely needs it
+ */
+
 int tioclinux(struct tty_struct *tty, unsigned long arg)
 {
 	char type, data;
+	int ret;
 
 	if (tty->driver.type != TTY_DRIVER_TYPE_CONSOLE)
 		return -EINVAL;
@@ -2181,17 +2197,23 @@
 		return -EPERM;
 	if (get_user(type, (char *)arg))
 		return -EFAULT;
+	ret = 0;
 	switch (type)
 	{
 		case 2:
-			return set_selection(arg, tty, 1);
+			acquire_console_sem();
+			ret = set_selection(arg, tty, 1);
+			release_console_sem();
+			break;
 		case 3:
-			return paste_selection(tty);
+			ret = paste_selection(tty);
+			break;
 		case 4:
 			unblank_screen();
-			return 0;
+			break;
 		case 5:
-			return sel_loadlut(arg);
+			ret = sel_loadlut(arg);
+			break;
 		case 6:
 			
 	/*
@@ -2201,24 +2223,33 @@
 	 * related to the kernel should not use this.
 	 */
 	 		data = shift_state;
-			return __put_user(data, (char *) arg);
+			ret = __put_user(data, (char *) arg);
+			break;
 		case 7:
 			data = mouse_reporting();
-			return __put_user(data, (char *) arg);
+			ret = __put_user(data, (char *) arg);
+			break;
 		case 10:
 			set_vesa_blanking(arg);
-			return 0;
+			break;;
 		case 11:	/* set kmsg redirect */
-			if (!capable(CAP_SYS_ADMIN))
-				return -EPERM;
-			if (get_user(data, (char *)arg+1))
-					return -EFAULT;
-			kmsg_redirect = data;
-			return 0;
+			if (!capable(CAP_SYS_ADMIN)) {
+				ret = -EPERM;
+			} else {
+				if (get_user(data, (char *)arg+1))
+					ret = -EFAULT;
+				else
+					kmsg_redirect = data;
+			}
+			break;
 		case 12:	/* get fg_console */
-			return fg_console;
+			ret = fg_console;
+			break;
+		default:
+			ret = -EINVAL;
+			break;
 	}
-	return -EINVAL;
+	return ret;
 }
 
 /*
--- linux-2.4.2-ac20/drivers/video/fbcon.c	Tue Mar 13 20:29:28 2001
+++ ac/drivers/video/fbcon.c	Tue Mar 13 21:11:29 2001
@@ -1149,8 +1149,8 @@
 	    	    start++;
 	    	}
 	    }
-	    console_conditional_schedule();
 	    scr_writew(c, d);
+	    console_conditional_schedule();
 	    s++;
 	    d++;
 	} while (s < le);
--- linux-2.4.2-ac20/kernel/printk.c	Tue Mar 13 20:29:30 2001
+++ ac/kernel/printk.c	Thu Mar 15 18:12:46 2001
@@ -267,6 +267,7 @@
 		spin_lock_irq(&logbuf_lock);
 		error = log_end - log_start;
 		spin_unlock_irq(&logbuf_lock);
+		break;
 	default:
 		error = -EINVAL;
 		break;
--- linux-2.4.2-ac20/lib/Makefile	Sat Dec 30 09:07:24 2000
+++ ac/lib/Makefile	Thu Mar 15 18:26:19 2001
@@ -10,7 +10,7 @@
 
 export-objs := cmdline.o
 
-obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o
+obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o bust_spinlocks.o
 
 ifneq ($(CONFIG_HAVE_DEC_LOCK),y) 
   obj-y += dec_and_lock.o
--- linux-2.4.2-ac20/lib/bust_spinlocks.c	Thu Jan  1 00:00:00 1970
+++ ac/lib/bust_spinlocks.c	Thu Mar 15 18:28:28 2001
@@ -0,0 +1,38 @@
+/*
+ * lib/bust_spinlocks.c
+ *
+ * Provides a minimal bust_spinlocks for architectures which don't have one of their own.
+ *
+ * bust_spinlocks() clears any spinlocks which would prevent oops, die(), BUG()
+ * and panic() information from reaching the user.
+ */
+
+#include <linux/kernel.h>
+#include <linux/spinlock.h>
+#include <linux/tty.h>
+#include <linux/wait.h>
+#include <linux/vt_kern.h>
+
+extern spinlock_t timerlist_lock;
+
+void bust_spinlocks(int yes)
+{
+	spin_lock_init(&timerlist_lock);
+	if (yes) {
+		oops_in_progress = 1;
+	} else {
+		int loglevel_save = console_loglevel;
+		unblank_screen();
+		oops_in_progress = 0;
+		/*
+		 * OK, the message is on the console.  Now we call printk()
+		 * without oops_in_progress set so that printk will give klogd
+		 * and the blankded console a poke.  Hold onto your hats...
+		 */
+		console_loglevel = 15;		/* NMI oopser may have shut the console up */
+		printk(" ");
+		console_loglevel = loglevel_save;
+	}
+}
+
+

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[Geert U. <ge...@li...>]

On Wed, 14 Mar 2001, James Simmons wrote:
> >>So the fbdev drivers would register PM with fbcon, not PCI, correct?
> >
> >Either that, or the fbdev would register with PCI (or whatever), _and_
> >fbcon would too independently. In that scenario, fbcon would only handle
> >things like disabling the cursor timer, while fbdev's would handle HW
> >issues. THe only problem is for fbcon to know that a given fbdev is
> >asleep, this could be an exported per-fbdev flag, an error code, or
> >whatever. In this case, fbcon can either buffer text input, or fallback
> >to the cfb working on the backed up fb image (that last thing can be
> >handled entirely within the fbdev I guess).

    [...]

>   As for fbcon knowing when it is asleep. Hum. We could have a flags to
> tell it to have text data updates to be placed in the shadow buffer
> (struct vc_datas->vc_screenbuffer) only;

Very simple to implement in the fbdev itself: just replace the drawing ops by
dummy drawing ops.

This can already be done now, by providing a dummy struct display_switch, and
in the future by providing dummy accels.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>But wouldn't falling back to dummycon prevent the driver specific
>suspend/resume calls from working?  Or at a minimum, make handling those
>calls more complex?

Not if suspend/resume are handled on the fbdev driver level. Dummycon
would only shutdown fbcon on explict open of /dev/fb. Also note it will be
possible to have only a serial console and use /dev/fb by itself. In this
case we don't even need dummycon since their is no VT support present.

>No, there does not need to be graphical images of the text console -- a
>simply text buffer would suffice.

See email to Ben.

>But what about things like GTKFb and
>Embedded QT?  They would certainly benefit from having a backup screen
>image, right?  I do not believe there is any way to determine if the
>console is in fact in a 'text' or graphical state.

Yes and it would not be hard to do this. I have the basic idea in the
email to Ben. As for console in text or graphical state take a look at
vt_ioctl.c:vt_ioctl() for KDGETMODE. You get back KD_TEXT or KD_GRAPHICS.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>>I'd go for a fallback to dummycon. It's of no use to waste power on
>>creating graphical images of the text console when asleep. And the
>>fallback to dummycon is needed anyway while a fbdev is opened (in
>>2.5.x).
>
>We do already have the backup image since we need to backup & restore the
>framebuffer content.

  What he is talking about is in 2.5.X when you explictly open /dev/fb it
will call take_over_console with dummy con. This allows for several
things. One is with this approach their is no chance of a conflict between
X/DRI and fbdev. Especially when we will have fbdev drivers using DMA
internally to preform console operations. For some hardware using DMA is
the only way fbdev can work and on some platforms fbcon is the only
choice. So things going into /dev/ttyX will not have a chance to interfere
with X.  The second reason is for security. It is possible to have a
program to open /dev/fb and see what is being typed on the fore ground
console. I sealed up those holes using the dummy con approach and some
test to see if the current process is local.
  Now for fbcon its simpler. Things get writing to the shadow buffer
(vc_screenbuf). When the console gets woken up update_screen is called.
While power down the shadow buffer can be written to which is much faster
than saving a image of the framebuffer. Of course if you still want to do
this such in the case of the X server then copy the image of the
framebuffer to regular ram. Then power down /dev/fb using some ioctl calls
provide.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>>So the fbdev drivers would register PM with fbcon, not PCI, correct?
>
>Either that, or the fbdev would register with PCI (or whatever), _and_
>fbcon would too independently. In that scenario, fbcon would only handle
>things like disabling the cursor timer, while fbdev's would handle HW
>issues. THe only problem is for fbcon to know that a given fbdev is
>asleep, this could be an exported per-fbdev flag, an error code, or
>whatever. In this case, fbcon can either buffer text input, or fallback
>to the cfb working on the backed up fb image (that last thing can be
>handled entirely within the fbdev I guess).

Hi!
  I had to give it some thought. I like to see this handles inside the
fbdev driver itself instead of inside fbcon. For 2.5.X it will be possible
to use /dev/fb with vgacon. Even better yet it will be possible to use
just a serial console and not use a VT but still use /dev/fb. So we will
want to to have fbdev doing power management itself. As for handling the
cursors I recently purposed a standardize cursor api so X can use it as
well via userland and a standard fbcon_cursor can be written. With this
api it would be easy to handle suspending and restoring the cursor for
fbcon for /dev/fb.
  As for fbcon knowing when it is asleep. Hum. We could have a flags to
tell it to have text data updates to be placed in the shadow buffer
(struct vc_datas->vc_screenbuffer) only;

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: LinuxFB access control idea

[James S. <jsi...@li...>]

>I've recently been having a look at writing an FB driver, and it occurs
>to me that it might be possible to control access to multiple virtual
>framebuffers by making use of the Linux VM system.

[snip]...

You are talking about userland management of access to the framebuffer.
This project doesn't really focus on this. Instead we are looking to make
fbcon and the console system leaner and meaner.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [linux-fbdev] Re: [Linux-fbdev-devel] pm3fb and modules ...

[James S. <jsi...@li...>]

>> You cannot go back as long as pm3fb is in use. In fact you can't go
>>back to vgacon anyway (exception: ruby from the linux-console project),
>>only to a different fbdev.
>
>mmm, will ruby need a 2.5.x kernel, or will it also work as a patch
>against 2.4.x ... (err is uppose the later since there is no 2.5.X yet
>anyway, am i right ?)

Yes it is against a 2.4.2 tree right now. I plan to place into 2.5.X. Note
the api for fbdev has changed to make the drivers simpler but you can back
port a ruby fbdev driver to standard 2.4. Their is a fbcon-accel.c that
does this. It requires a little patching to fbcon.c tho. I plan to use
fbcon-accel.c at first for 2.5.X or if some driver writer is brave they
could make it part of their driver for 2.4.X now. Also under ruby it is
possible to use /dev/fb without fbcon. I did it with vga16fb and vgacon to
test the fbdev driver. The fbdev driver has to be able to set the video
state back to vga text mode. This can be done in a function that can be
called when the module unloads and when you close /dev/fb. Please note
ruby is a developement kernel which needs more work.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Is a FontCache worth implementing?

[James S. <jsi...@li...>]

>Yes, but this is not the same mesa version that is used by X and which
>may be HW accelerated on some board,s is it ?

This was before DRI was available.

>So we would need a second opengl library lying around for fbdev opengl,
>this is not nice, better to do it right and have fbdev to play nice with
>dri/drm.

I plan to after I'm done with the console project. I like to see something
that is a replacement for both userland interfaces.

>What about registering with drm, and then use the drm kernel module for
>doing dma ? Is there something wrong with it ?

I feel a little shaking about that. DRI was not designed with that in
mind. DRI focus was DMA userland whereas a fbcon driver would be using
DMA internally. DRI doesn't take advantage of things like kio buffers
which would be really fast. Nor does it really support pci dma or the
pci dma standard (linux/Documentation/DMA-mapping.txt). To not step on
DRI toes tho we need to provide the console mode <-> graphics mode
ability. I think this is of course will have to wait until 2.5.X. I knwo
linus will not except the console mode <-> graphics idea for 2.4.X but it
will definetly go into 2.5.X.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net