linuxconsole-dev

Re: status

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

> Any patches in the meantime?  I have a few changes I can pass to you:

Yes of course!!!!

> 1. optimized putcs to speed up scrolling by 2-3x.  (it's a small patch
> but it already outperforms fb-2.4 especially at high color depths).
> Compared with the previous patch I submitted, this change is
> non-intrusive, so no other changes are required.
>
> 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes
> only)
> 
> 3. logo drawing for directcolor visuals.

Please send me those patches ASAP!!! I will linclude them right away.
 
> The above should complete softaccel support for most hardware except for
> the more esoteric ones (mostly authored by Geert).

Geert is busy porting the Amigia driver to the new api. That means all the 
ilbm, iplan stuff will go away :-) 

> Also cfbcursor is a bit misleading, no?  It implies support for
> packed-pixels only, but I already  use it with vga16fb.

OOps. You are right. What should we call it?

Re: status

[Antonino D. <ad...@po...>]

On Fri, 2002-11-22 at 22:52, James Simmons wrote:
> 
> Hi folks!!!
> 
>    Just to let you know where I am for the fbdev developement. I finished 
> off the latest api changes. The cursor api has been cleaned up and it uses 
> fb_image struct. This makes life easier. 
>    I ported over the ATI 128 driver to the latest changes. I finished the 
> 3Dfx driver yesterday and got the ATI mach 64 driver done this morning.
> I will test it tomorrow. Then I will finsih up the NVIDIA driver. After 
> that I'm going to push the code to linus. 
Any patches in the meantime?  I have a few changes I can pass to you:

1. optimized putcs to speed up scrolling by 2-3x.  (it's a small patch
but it already outperforms fb-2.4 especially at high color depths).
Compared with the previous patch I submitted, this change is
non-intrusive, so no other changes are required.

2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes
only)

3. logo drawing for directcolor visuals.

The above should complete softaccel support for most hardware except for
the more esoteric ones (mostly authored by Geert).

Also cfbcursor is a bit misleading, no?  It implies support for
packed-pixels only, but I already  use it with vga16fb.

Tony 

status

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

Hi folks!!!

   Just to let you know where I am for the fbdev developement. I finished 
off the latest api changes. The cursor api has been cleaned up and it uses 
fb_image struct. This makes life easier. 
   I ported over the ATI 128 driver to the latest changes. I finished the 
3Dfx driver yesterday and got the ATI mach 64 driver done this morning.
I will test it tomorrow. Then I will finsih up the NVIDIA driver. After 
that I'm going to push the code to linus. 
   I started to hack at fbcon.c but realized it is such a mess I am going 
to rewrite it from scratch. This will be after the push to linus. I plan 
to use MDA console and create a modular fbcon that I can play with at 
will. 
   The other annoucement is I have started to look for funding for this 
developement. At present I haven't found anything. I realized for the 
fbdev and console changes to be done I need to devote all my time to do 
this. To do this will require funding so I can pay my most basic bills. 
Wish me luck.

Mips input changes etc.

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

Vojtech I have a few changes that I want your approval for. I first 
removed aux_device_present. We don't need it anymore. The second change is 
I toke a hack at porting the mips keyboard drivers over to input api. I do 
have the hardware to test it out but the mips platform is sadly way 
behind Linus tree. I still like to submit it tho. Do you want me to commit 
it or me post a diff first.

Re: various related projects...

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

> linuxconsole, linux-input, fbdev and ruby 
>  
> I'm a bit confused about what all these related projects are.   
> It seems that they all relate to the much needed (from what I  
> have been told) untangling of the console and input layers of the Linux 
> kernel.  Would someone mind giving a quick rundown on the various 
> projects, their status, what their purpose is and who they effect? 
>  
> I really apprciate it.  Thanks. 

No problem. 

   When linux first started out the console system was totally based 
around the VGA text with the classic PC keyboard. Over time as more 
platforms where added to the linux project there was no standard way 
to write new drivers and since Linux was highly x86 centeric all the 
new platforms where forced to make there keyboard and video hardware 
behave like PC hardware. Over time we seen enormous amounts of code 
repeated over and over again in various drivers.
   Then this project was started. The idea was to make the console system 
a abstract of other well designed subsystems. The console system is 
basically a keyboard and a display. So the idea was to create a layer to 
handle keyboards independent of the console system and creaet a layer for 
teh display independent of teh console system. Thus we ended up with the 
input layer and the fbdev layer. Each can now function on there own and 
together they can be combined to form a VT console. This makes for much 
smaller cleaner code.

What has gone in:

1) input layer and console interface to it.

2) fbdev api changes and console seperation from it. Well almost. Linus 
   has to take my last set of changes.

What is to be done:

1) The console system itself has to go threw a major rewrite. Basically we 
   have to move away from the old PC centeric design. This is what the 
   linuxconsole project aims to do.

Ruby is the name of our kernel tree in CVS. We named each set of kernel 
changes after a gem. Before we had saphhire and emarald.

 

various related projects...

[Adam H. <ada...@gm...>]

linuxconsole, linux-input, fbdev and ruby 
 
I'm a bit confused about what all these related projects are.   
It seems that they all relate to the much needed (from what I  
have been told) untangling of the console and input layers of the Linux 
kernel.  Would someone mind giving a quick rundown on the various 
projects, their status, what their purpose is and who they effect? 
 
I really apprciate it.  Thanks. 
 
--adam 

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

Re: ruby cvs first look

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

> >I would assign the beeper to the first keyboard and make it all
> >configurable by the user - you really only need to have one keyboard,
> >one screen, and one beeper running after boot and the rest
> >(reassignment, etc) can be taken care of by the init scripts.
> 
> Agree. I am child of PC-compatible hardware.

So it will be. I will add a handler to struct vt_struct for the beeper. 

> Of course /dev/ttyXX is not a keyboard device and VT may have a beeper
> handler if keyboard is beeperless.

Which is okay. 

Re: ruby cvs first look

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

> Oops , IMHO You destroy all ruby cvs.

:-( I back track to bring things up to speed. The good news is it is not 
far off where we where before. The biggest problem right now is the core 
code in Linus tree is broken so I can't test the latest stuff :-(

> I test vt.c cvs version 1.123 with single console tty driver.
> It work flawless. I push changes in the my own code.
> Configuration VGA + 2 DUMMY == 3 XFree servers == 3 keyboards
  

Re: ruby cvs first look

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

> Hi, James
> 
> Yes it's boot!
> 
> Around the code popup currcons mismatch.
> find_vc() vc_allocate() good only for one console.

Applied. Will be fixing these bugs today. Once I fix the PC speaker issue 
we will have multihead back. I will update dummycon.c today to the new 
console changes so you can have multihead.

X with event interface

[Andreas S. <an...@sc...>]

This patch (written by Zephaniah E. Hull <wa...@de...>) adds
an event interface to X. this is just for mice at the moment, but
he works on keyboards right now.

It uses the Mouse name as seen in /proc/bus/input/devices in the
Name filed. the XF86Config section looks like this, then:

Section "InputDevice"
    Identifier  "Mouse1"
    Driver      "mouse"
    Option      "Protocol"      "evdev"
    Option      "Device"        "A4Tech USB Optical Mouse"
    Option      "Buttons"       "9"
    Option      "ZAxisMapping"  "6 7 8 9"
EndSection

I am using it right now on my multi-Xserver machine.

diff -ur build-tree/xc/programs/Xserver/hw/xfree86/os-support/linux/Imakefile build-tree.mine/xc/programs/Xserver/hw/xfree86/os-support/linux/Imakefile
--- xc/programs/Xserver/hw/xfree86/os-support/linux/Imakefile	2000-11-16 14:45:03.000000000 -0500
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/Imakefile	2002-11-09 06:06:23.000000000 -0500
@@ -50,7 +50,8 @@
        $(AXP_OBJ) lnx_kmod.o lnx_agp.o
 
 INCLUDES = -I$(XF86COMSRC) -I$(XF86OSSRC) -I. -I$(SERVERSRC)/include \
-           -I$(XINCLUDESRC) -I$(EXTINCSRC) -I$(XF86OSSRC)/shared
+           -I$(XINCLUDESRC) -I$(EXTINCSRC) -I$(XF86OSSRC)/shared \
+           -I$(SERVERSRC)/mi
 
 RESDEFINES = -DUSESTDRES
 
diff -ur build-tree/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_mouse.c build-tree.mine/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_mouse.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_mouse.c	1999-05-17 09:17:18.000000000 -0400
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_mouse.c	2002-11-09 11:21:23.000000000 -0500
@@ -6,8 +6,24 @@
 
 #include "X.h"
 #include "xf86.h"
+#include "xf86Priv.h"
+#include "xf86_OSlib.h"
 #include "xf86Xinput.h"
 #include "xf86OSmouse.h"
+#include "mipointer.h"
+#include <linux/input.h>
+
+#define BITS_PER_LONG (sizeof(long) * 8)
+#define NBITS(x) ((((x)-1)/BITS_PER_LONG)+1)
+#define OFF(x)  ((x)%BITS_PER_LONG)
+#define LONG(x) ((x)/BITS_PER_LONG)
+#define test_bit(bit, array)    ((array[LONG(bit)] >> OFF(bit)) & 1)
+
+/* Names of protocols that are handled internally here. */
+static const char *internalNames[] = {
+	"evdev",
+	NULL
+};
 
 static int
 SupportedInterfaces(void)
@@ -15,6 +31,260 @@
     return MSE_SERIAL | MSE_BUS | MSE_PS2 | MSE_XPS2 | MSE_AUTO;
 }
 
+static const char **
+BuiltinNames(void)
+{
+    return internalNames;
+}
+
+static Bool
+CheckProtocol(const char *protocol)
+{
+    int i;
+
+    for (i = 0; internalNames[i]; i++)
+	if (xf86NameCmp(protocol, internalNames[i]) == 0)
+	    return TRUE;
+    return FALSE;
+}
+
+typedef struct _evdevMseRec {
+    int packetSize;
+    int buttons;
+} evdevMseRec, *evdevMsePtr;
+
+static int
+evdevFindMouse (const char *want)
+{
+    char dev[20];
+    char name[256] = "";
+    int fd, i;
+
+    i = 0;
+    while (1) {
+	snprintf(dev, sizeof(dev), "/dev/input/event%d", i++); 
+	SYSCALL(fd = open (dev, O_RDWR | O_NONBLOCK));
+	if (fd == -1)
+	    return -1;
+	ioctl(fd, EVIOCGNAME(sizeof(name)), name);
+	if (xf86NameCmp(name, want) == 0) {
+	    return fd;
+	}
+	close(fd);
+    }
+    return -1;
+}
+
+static void
+evdevReadInput(InputInfoPtr pInfo)
+{
+    MouseDevPtr pMse;
+    evdevMsePtr evdevMse;
+    struct input_event *ev;
+    int n, bit; 
+
+    pMse = pInfo->private;
+    ev = (struct input_event *) pMse->buffer;
+    evdevMse = pMse->mousePriv;
+
+    if (pInfo->fd == -1)
+	return;
+
+    do {
+	int dx = 0, dy = 0, dz = 0, dw = 0;
+	n = read(pInfo->fd, pMse->buffer, sizeof(struct input_event));
+	if (n == -1) {
+	    xf86Msg(X_ERROR, "%s: Error in reading! (%s) Disabiling.\n",
+		    pInfo->name, strerror(errno));
+	    RemoveEnabledDevice(pInfo->fd);
+	    xf86RemoveSIGIOHandler(pInfo->fd);
+	    close (pInfo->fd);
+	    pMse->device->public.on = FALSE;
+	    pInfo->fd = -1;
+	    return;
+	}
+	if (n != sizeof(struct input_event)) {
+	    xf86Msg(X_WARNING, "%s: incomplete packet, size %d\n", pInfo->name, n);
+	    return;
+	}
+
+	switch (ev->type) {
+	    case EV_REL:
+		switch (ev->code) {
+		    case REL_X:
+			dx += ev->value;
+			break;
+		    case REL_Y:
+			dy += ev->value;
+			break;
+		    case REL_Z:
+		    case REL_WHEEL:
+			dz -= ev->value;
+			break;
+		    case REL_HWHEEL:
+			dw -= ev->value;
+			break;
+		}
+		break;
+	    case EV_KEY:
+		if ((ev->code < BTN_MOUSE) || (ev->code >= BTN_JOYSTICK))
+		    break;
+		switch (ev->code) {
+		    case BTN_RIGHT: bit = 1 << 0; break;	/* 1 */
+		    case BTN_MIDDLE: bit = 1 << 1; break;	/* 2 */
+		    case BTN_LEFT: bit = 1 << 2; break;		/* 3 */
+		    default: bit = 1 << (ev->code - BTN_MOUSE); break;
+		}
+		evdevMse->buttons &= ~bit;
+		if (ev->value)
+		    evdevMse->buttons |= bit;
+		break;
+	}
+
+	pMse->PostEvent(pInfo, evdevMse->buttons, dx, dy, dz, dw);
+    } while (xf86WaitForInput(pInfo->fd, 0));
+
+    return;
+}
+
+static void
+evdevSigioReadInput (int fd, void *closure)
+{
+    evdevReadInput ((InputInfoPtr) closure);
+}
+
+static int
+evdevMouseProc(DeviceIntPtr pPointer, int what)
+{
+    InputInfoPtr pInfo;
+    MouseDevPtr pMse;
+    evdevMsePtr evdevMse;
+    unsigned char map[MSE_MAXBUTTONS + 1];
+    char *dev;
+    int i, blocked;
+
+    pInfo = pPointer->public.devicePrivate;
+    pMse = pInfo->private;
+    pMse->device = pPointer;
+    evdevMse = pMse->mousePriv;
+
+    switch (what) {
+    case DEVICE_INIT: 
+	pPointer->public.on = FALSE;
+
+	for (i = 0; i < MSE_MAXBUTTONS; ++i)
+	    map[i + 1] = i + 1;
+
+	InitPointerDeviceStruct((DevicePtr)pPointer, map, 
+				min(pMse->buttons, MSE_MAXBUTTONS),
+				miPointerGetMotionEvents, pMse->Ctrl,
+				miPointerGetMotionBufferSize());
+
+	/* X valuator */
+	xf86InitValuatorAxisStruct(pPointer, 0, 0, -1, 1, 0, 1);
+	xf86InitValuatorDefaults(pPointer, 0);
+	/* Y valuator */
+	xf86InitValuatorAxisStruct(pPointer, 1, 0, -1, 1, 0, 1);
+	xf86InitValuatorDefaults(pPointer, 1);
+	xf86MotionHistoryAllocate(pInfo);
+	break;
+
+    case DEVICE_ON:
+	dev = xf86SetStrOption (pInfo->options, "Device", NULL);
+	if ((pInfo->fd = evdevFindMouse (dev)) == -1) {
+	    xf86Msg(X_WARNING, "%s: cannot open input device\n", pInfo->name);
+	    return BadRequest;
+	}
+
+	xf86FlushInput(pInfo->fd);
+	if (!xf86InstallSIGIOHandler (pInfo->fd, evdevSigioReadInput, pInfo))
+	    AddEnabledDevice(pInfo->fd);
+	pMse->lastButtons = 0;
+	pMse->emulateState = 0;
+	evdevMse->buttons = 0;
+	pPointer->public.on = TRUE;
+	/*
+	 * send button up events for sanity. If no button down is pending
+	 * xf86PostButtonEvent() will discard them. So we are on the safe side.
+	 */
+	blocked = xf86BlockSIGIO ();
+	for (i = 1; i <= 5; i++)
+	    xf86PostButtonEvent(pPointer,0,i,0,0,0);
+	xf86UnblockSIGIO (blocked);
+	break;
+
+    case DEVICE_OFF:
+    case DEVICE_CLOSE:
+	if (pInfo->fd != -1) {
+	    RemoveEnabledDevice(pInfo->fd);
+	    xf86RemoveSIGIOHandler(pInfo->fd);
+	    close (pInfo->fd);
+	    pInfo->fd = -1;
+	}
+	pPointer->public.on = FALSE;
+	usleep(300000);
+	break;
+    }
+    return Success;
+}
+
+
+/* This function is called when the protocol is "evdev". */
+static Bool
+evdevPreInit(InputInfoPtr pInfo, const char *protocol, int flags)
+{
+    unsigned long evtype_bits[NBITS(KEY_MAX)];
+    unsigned long evkey_bits[NBITS(KEY_MAX)];
+    MouseDevPtr pMse = pInfo->private;
+    char *dev;
+    int i, j;
+
+    pMse->protocol = protocol;
+    xf86Msg(X_CONFIG, "%s: Protocol: %s\n", pInfo->name, protocol);
+
+    /* Collect the options, and process the common options. */
+    xf86CollectInputOptions(pInfo, NULL, NULL);
+    xf86ProcessCommonOptions(pInfo, pInfo->options);
+
+    dev = xf86SetStrOption (pInfo->options, "Device", NULL);
+    if ((pInfo->fd = evdevFindMouse (dev)) == -1)
+	return FALSE;	/* FIXME: Print a message or something too? */
+
+    ioctl(pInfo->fd, EVIOCGBIT(0, EV_MAX), evtype_bits);
+    if (test_bit(EV_KEY, evtype_bits)) {
+	ioctl(pInfo->fd, EVIOCGBIT(EV_KEY, EV_MAX), evkey_bits);
+	i = BTN_LEFT;
+	pMse->buttons = 0;
+	for (i = BTN_LEFT, j = 0; i <= BTN_BACK; i++)
+	    if (test_bit(i, evkey_bits))
+		pMse->buttons++;
+    }
+
+    close(pInfo->fd);
+    pInfo->fd = -1;
+
+    if (sizeof(struct input_event) <= sizeof(pMse->protoBuf))
+	pMse->buffer = pMse->protoBuf;
+    else
+	pMse->buffer = xalloc(sizeof(struct input_event));
+    pMse->mousePriv = xalloc(sizeof(evdevMseRec));;
+    if ((pMse->buffer == NULL) || (pMse->mousePriv == NULL)) {
+	xf86Msg(X_ERROR, "%s: cannot allocate buffer\n", pInfo->name);
+	xfree(pMse);
+	return FALSE;
+    }
+
+    pMse->CommonOptions(pInfo);
+
+    /* Setup the local procs. */
+    pInfo->device_control = evdevMouseProc;
+    pInfo->read_input = evdevReadInput;
+
+    pInfo->flags |= XI86_CONFIGURED;
+
+    return TRUE;
+}
+
 OSMouseInfoPtr
 xf86OSMouseInit(int flags)
 {
@@ -24,6 +294,9 @@
     if (!p)
 	return NULL;
     p->SupportedInterfaces = SupportedInterfaces;
+    p->CheckProtocol = CheckProtocol;
+    p->BuiltinNames = BuiltinNames;
+    p->PreInit = evdevPreInit;
     return p;
 }
 

Re: ruby cvs first look

[Aivils S. <Aiv...@un...>]

>On Fri, Nov 08, 2002 at 07:54:41PM +0000, James Simmons wrote:
>
>> > Yes it's boot!
>> >
>> > Around the code popup currcons mismatch.
>> > find_vc() vc_allocate() good only for one console.
>>
>>    I know :-( The current problem is the beeper and the keyboard. In the
>> original ruby we didn't have the beeper converted over to the input api.
>> This made life easier. Now we do. This means both the keyboard and
beeper
>> are registered to the keyboard console handler. Because the old ruby
code
>> assumed it was always a keyboard this means the beeper is seen as a
>> keyboard. Of course this is bad!! So what is the solution?
>>
>>    Well first we to see what possible combinations we can have. They
are:
>>
>> 1) The beeper is built into the keyboard. Sparc keyboard i.e
>>
>> 2) Seperate beepers but we have more than one.
>>
>> 3) Only one beeper.
>>
>> Now 1 and 3 are very common. The first solution I thought of was having
>> two struct input_handlers in struct vt_struct. One for keyboard and the
>> second for the beeper. For the keyboard with the built in speaker both
>> handlers would point to the same device. For the PC we have to attach
the
>> speaker to the first VT we find without a speaker. This can be easliy
>> handled by first testing the incoming input device handles keys. Then we
>> test it right away to see if it has a speaker. Now the question is what
do
>> we do for a "global" speaker. For example I have two PS/2 keybaords but
>> one PC speaker. Do we share it.Then there is the issue if two users want
>> to reprogram the  beeper to be at two different rates. The hardware
can't
>> be at two different rates at the same time. Vojtech do you have any
ideas
>> on how to handle this?
>
>I would assign the beeper to the first keyboard and make it all
>configurable by the user - you really only need to have one keyboard,
>one screen, and one beeper running after boot and the rest
>(reassignment, etc) can be taken care of by the init scripts.

Agree. I am child of PC-compatible hardware.
Of course /dev/ttyXX is not a keyboard device and VT may have a beeper
handler
if keyboard is beeperless.

Aivils Stoss

Re: ruby cvs first look

[Aivils S. <Aiv...@un...>]

>> small patch allow me start ruby with single VGA, single XFree.
>
>I will apply the patches tomorrow morning. Thanks.

Oops , IMHO You destroy all ruby cvs.
I test vt.c cvs version 1.123 with single console tty driver.
It work flawless. I push changes in the my own code.
Configuration VGA + 2 DUMMY == 3 XFree servers == 3 keyboards


Aivils Stoss

Re: ruby cvs first look

[Vojtech P. <vo...@su...>]

On Fri, Nov 08, 2002 at 07:54:41PM +0000, James Simmons wrote:

> > Yes it's boot!
> > 
> > Around the code popup currcons mismatch.
> > find_vc() vc_allocate() good only for one console.
> 
>    I know :-( The current problem is the beeper and the keyboard. In the 
> original ruby we didn't have the beeper converted over to the input api. 
> This made life easier. Now we do. This means both the keyboard and beeper 
> are registered to the keyboard console handler. Because the old ruby code 
> assumed it was always a keyboard this means the beeper is seen as a 
> keyboard. Of course this is bad!! So what is the solution?
> 
>    Well first we to see what possible combinations we can have. They are:
> 
> 1) The beeper is built into the keyboard. Sparc keyboard i.e
> 
> 2) Seperate beepers but we have more than one.
> 
> 3) Only one beeper. 
> 
> Now 1 and 3 are very common. The first solution I thought of was having 
> two struct input_handlers in struct vt_struct. One for keyboard and the 
> second for the beeper. For the keyboard with the built in speaker both 
> handlers would point to the same device. For the PC we have to attach the 
> speaker to the first VT we find without a speaker. This can be easliy 
> handled by first testing the incoming input device handles keys. Then we 
> test it right away to see if it has a speaker. Now the question is what do 
> we do for a "global" speaker. For example I have two PS/2 keybaords but 
> one PC speaker. Do we share it.Then there is the issue if two users want 
> to reprogram the  beeper to be at two different rates. The hardware can't 
> be at two different rates at the same time. Vojtech do you have any ideas 
> on how to handle this?

I would assign the beeper to the first keyboard and make it all
configurable by the user - you really only need to have one keyboard,
one screen, and one beeper running after boot and the rest
(reassignment, etc) can be taken care of by the init scripts.

> > small patch allow me start ruby with single VGA, single XFree.
> 
> I will apply the patches tomorrow morning. Thanks.

-- 
Vojtech Pavlik
SuSE Labs

Re: [Linux-fbdev-devel] Re: [BK console] console updates.

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

> >    Along with the new fbdev api I also have rewritten the console layer.
> > The goals are:
> 
> Current 2.5.45 (and previous 2.5's) has funny problems on my vesafb
> machines [like half of letters appearing during emacs session, to the
> point you do ^L to repaint]. I hope this fixes it....

It will. I'm waiting for the latest patches whcih do fix all those 
problems. As soon as I get them I will post a updated patch for the fbdev 
changes. 

Re: Linux-2.5 + Recent Framebuffer Code + Bitkeeper

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

> Adam> Do I want to clone my local linux-2.5 repository in to a new
> Adam> linuxconsole directory and then 'pull' the changes from the
> Adam> linuxconsole.bkbits.com tree into it?
> 
> This is what I'd do to get a clone of the linuxconsole trees:
> 
> First, surf to http://linuxconsole.bkbits.net and get the most recent
> tags from the dev and stable trees.  (As of now those are v2.5.34 for
> dev and lia64-v2.5.45 for stable.)  Given that, and a clone of Linus'
> tree in linux-2.5, I'd do:

dev is really old and really broken. Stable is the old really one that 
works.

> to Linus' current tree).  There are still more not on bkbits.  One rep
> that may be of interest if you are pulling linuxconsole is at:
> 
>   bk://fbdev.bkbits.net/fbdev-2.5

Just one note. fbdev conflicts with the console BK tree. At the present 
time I'm working heavily on the fbdev tree to get it ready for Linus. I'm 
ruby-tizing the fbdev tree as much as possible. By that I mean killing on 
currcon and such. This will make it easy to work in under the console 
tree. I already managed to seperate out the console code from all the low 
level drivers.

Re: ruby cvs first look

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

> Yes it's boot!
> 
> Around the code popup currcons mismatch.
> find_vc() vc_allocate() good only for one console.

   I know :-( The current problem is the beeper and the keyboard. In the 
original ruby we didn't have the beeper converted over to the input api. 
This made life easier. Now we do. This means both the keyboard and beeper 
are registered to the keyboard console handler. Because the old ruby code 
assumed it was always a keyboard this means the beeper is seen as a 
keyboard. Of course this is bad!! So what is the solution?

   Well first we to see what possible combinations we can have. They are:

1) The beeper is built into the keyboard. Sparc keyboard i.e

2) Seperate beepers but we have more than one.

3) Only one beeper. 

Now 1 and 3 are very common. The first solution I thought of was having 
two struct input_handlers in struct vt_struct. One for keyboard and the 
second for the beeper. For the keyboard with the built in speaker both 
handlers would point to the same device. For the PC we have to attach the 
speaker to the first VT we find without a speaker. This can be easliy 
handled by first testing the incoming input device handles keys. Then we 
test it right away to see if it has a speaker. Now the question is what do 
we do for a "global" speaker. For example I have two PS/2 keybaords but 
one PC speaker. Do we share it.Then there is the issue if two users want 
to reprogram the  beeper to be at two different rates. The hardware can't 
be at two different rates at the same time. Vojtech do you have any ideas 
on how to handle this?

> small patch allow me start ruby with single VGA, single XFree.

I will apply the patches tomorrow morning. Thanks.

ruby cvs first look

[Aivils S. <Aiv...@un...>]

Hi, James

Yes it's boot!

Around the code popup currcons mismatch.
find_vc() vc_allocate() good only for one console.

small patch allow me start ruby with single VGA, single XFree.

diff -Nurp linux-2.5.45/drivers/char/consolemap.c
linux-2.5.45-chg/drivers/char/consolemap.c
--- linux-2.5.45/drivers/char/consolemap.c    Sat Nov  2 01:27:32 2002
+++ linux-2.5.45-chg/drivers/char/consolemap.c     Fri Nov  8 00:44:00 2002
@@ -234,7 +234,7 @@ static void update_user_maps(struct vc_d
     struct uni_pagedir *p, *q = NULL;
     int i;

-    for (i = 0; i < MAX_NR_CONSOLES; i++) {
+    for (i = 0; i < MAX_NR_USER_CONSOLES; i++) {
          struct vc_data *tmp = vc->display_fg->vc_cons[i];

          if (!tmp)
@@ -379,7 +379,7 @@ static int con_unify_unimap(struct vc_da
     struct uni_pagedir *q;
     int i, j, k;

-    for (i = 0; i < MAX_NR_CONSOLES; i++) {
+    for (i = 0; i < MAX_NR_USER_CONSOLES; i++) {
          struct vc_data *tmp = vc->display_fg->vc_cons[i];

          if (!tmp)
@@ -670,7 +670,7 @@ console_map_init(void)
     struct vt_struct *vt = vt_cons;
     int i;

-    for (i = 0; i < MAX_NR_CONSOLES; i++) {
+    for (i = 0; i < MAX_NR_USER_CONSOLES; i++) {
          struct vc_data *vc = vt->vc_cons[i];

          if (vc && !*vc->vc_uni_pagedir_loc)
diff -Nurp linux-2.5.45/drivers/char/keyboard.c
linux-2.5.45-chg/drivers/char/keyboard.c
--- linux-2.5.45/drivers/char/keyboard.c      Sat Nov  2 01:27:32 2002
+++ linux-2.5.45-chg/drivers/char/keyboard.c  Thu Nov  7 23:24:37 2002
@@ -45,6 +45,7 @@ extern void ctrl_alt_del(void);
 void compute_shiftstate(void);
 struct pt_regs *kbd_pt_regs;
 EXPORT_SYMBOL(kbd_pt_regs);
+extern int do_poke_blanked_console;

 /*
  * Handler Tables.
diff -Nurp linux-2.5.45/drivers/char/vc_screen.c
linux-2.5.45-chg/drivers/char/vc_screen.c
--- linux-2.5.45/drivers/char/vc_screen.c     Sat Nov  2 01:27:32 2002
+++ linux-2.5.45-chg/drivers/char/vc_screen.c      Fri Nov  8 00:52:08 2002
@@ -91,7 +91,7 @@ vcs_size(struct inode *inode)
     else
          currcons--;

-    vc = vt_cons->vc_cons[currcons];
+    vc = vt_cons->vc_cons[currcons - vt_cons->first_vc];

     if (!vc)
          return -ENXIO;
@@ -168,7 +168,7 @@ vcs_read(struct file *file, char *buf, s
     }
     ret = -ENXIO;

-    vc = vt_cons->vc_cons[currcons];
+    vc = vt_cons->vc_cons[currcons - vt_cons->first_vc];

     if (!vc)
          goto unlock_out;
@@ -343,7 +343,7 @@ vcs_write(struct file *file, const char
     }
     ret = -ENXIO;

-    vc = vt_cons->vc_cons[currcons];
+    vc = vt_cons->vc_cons[currcons - vt_cons->first_vc];

     if (!vc)
          goto unlock_out;
@@ -504,7 +504,7 @@ vcs_open(struct inode *inode, struct fil
 {
     unsigned int currcons = minor(inode->i_rdev) & 127;

-    if (currcons && !vt_cons->vc_cons[currcons-1])
+    if (currcons && !vt_cons->vc_cons[currcons-1-vt_cons->first_vc])
          return -ENXIO;
     return 0;
 }
diff -Nurp linux-2.5.45/drivers/char/vt_ioctl.c
linux-2.5.45-chg/drivers/char/vt_ioctl.c
--- linux-2.5.45/drivers/char/vt_ioctl.c      Sat Nov  2 01:27:32 2002
+++ linux-2.5.45-chg/drivers/char/vt_ioctl.c  Fri Nov  8 01:01:08 2002
@@ -1094,7 +1094,7 @@ int vt_ioctl(struct tty_struct *tty, str
                              return i;
                         }
                    }
-
+                   vc->vt_newvt = -1;
                    /*
                     * When we actually do the console switch,
                     * make sure we are atomic with respect to
diff -Nurp linux-2.5.45/drivers/video/console/Makefile
linux-2.5.45-chg/drivers/video/console/Makefile
--- linux-2.5.45/drivers/video/console/Makefile    Sat Nov  2 01:51:14 2002
+++ linux-2.5.45-chg/drivers/video/console/Makefile     Thu Nov  7 23:33:24
2002
@@ -11,7 +11,7 @@ export-objs      := fbcon.o fbcon-accel.o

 # Each configuration option enables a list of files.

-obj-$(CONFIG_DUMMY_CONSOLE)       += dummycon.o
+#obj-$(CONFIG_DUMMY_CONSOLE)       += dummycon.o
 obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o
 obj-$(CONFIG_PROM_CONSOLE)        += promcon.o promcon_tbl.o
 obj-$(CONFIG_STI_CONSOLE)         += sticon.o sticore.o


Aivils Stoss

Re: 2.5 bk, input driver and dell i8100 nib+pad

[James H. C. Jr. <cl...@jh...>]

>>>>> "David" == David Woodhouse <dw...@in...> writes:

David> Weird. Does it come back to life if you suspend to RAM and
David> resume? Does the 'mouse' get detected as a Synaptics Touchpad
David> by the changed psmouse.c?

I have to do a new compile with the csets from overnight for the htree
bug before I can test that.  But from /var/log I see:

    kernel: input: PS/2 Synaptics TouchPad on isa0060/serio1

with the patch and w/o the patch I had:

    kernel: input: PS/2 Generic Mouse on isa0060/serio1

so that part of it at least was fixed.

-JimC

Re: 2.5 bk, input driver and dell i8100 nib+pad

[David W. <dw...@in...>]

cl...@jh... said:
>  Of course; I even incremented my EXTRAVERSION for the new kernel, and
> the import and compile was done in a fresh clone....

Weird. Does it come back to life if you suspend to RAM and resume? Does the 
'mouse' get detected as a Synaptics Touchpad by the changed psmouse.c?

--
dwmw2

Re: 2.5 bk, input driver and dell i8100 nib+pad

[James H. C. Jr. <cl...@jh...>]

>>>>> "David" == David Woodhouse <dw...@in...> writes:

>> The patch in the referenced post did not fix this for me in 2.5 bk
>> current.  The nib continued to do nothing.

David> You need to reboot or suspend and resume, Just unloading and
David> reloading the psmouse module isn't sufficient.

Of course; I even incremented my EXTRAVERSION for the new kernel, and
the import and compile was done in a fresh clone....

-JimC

Re: 2.5 bk, input driver and dell i8100 nib+pad

[David W. <dw...@in...>]

cl...@jh... said:
>  The patch in the referenced post did not fix this for me in 2.5 bk
> current.  The nib continued to do nothing. 

You need to reboot or suspend and resume, Just unloading and reloading the 
psmouse module isn't sufficient.

--
dwmw2

Re: 2.5 bk, input driver and dell i8100 nib+pad

[James H. C. Jr. <cl...@jh...>]

>>>>> "David" == David Woodhouse <dw...@in...> writes:

>> Trying out 2.5, I've got only a partially working mouse.  The usb
>> mouse is fully functional, as are both sets of buttons on the
>> notebook.  The mouse pad works, but the nib is ignored.

David> http://lists.insecure.org/lists/linux-kernel/2002/Oct/7774.html

The patch in the referenced post did not fix this for me in 2.5 bk
current.  The nib continued to do nothing.

-JimC

Re: 2.5 bk, input driver and dell i8100 nib+pad

[James H. C. Jr. <cl...@jh...>]

>>>>> "David" == David Woodhouse <dw...@in...> writes:

>> Of course, I only ever use the nib and only noticed that the pad
>> was working by accident.

>> I seem to recall a similar post some time back, but cannot find it
>> in my archives.

David> http://lists.insecure.org/lists/linux-kernel/2002/Oct/7774.html

I'll give that a try.  Thanks.

-JimC

Re: 2.5 bk, input driver and dell i8100 nib+pad

[David W. <dw...@in...>]

cl...@jh... said:
> Trying out 2.5, I've got only a partially working mouse.  The usb
> mouse is fully functional, as are both sets of buttons on the
> notebook.  The mouse pad works, but the nib is ignored.

> Of course, I only ever use the nib and only noticed that the pad was
> working by accident.

> I seem to recall a similar post some time back, but cannot find it in
> my archives.   

http://lists.insecure.org/lists/linux-kernel/2002/Oct/7774.html

I've since been playing with the docs for the SuperIO chip but I'm not 
convinced we can actually talk to all four PS/2 ports individually unless 
we reflash the 8051 firmware on it, which I don't really want to play with.

--
dwmw2

Re: 2.5 bk, input driver and dell i8100 nib+pad

[James H. C. Jr. <cl...@jh...>]

Here is the input-relevant section of the .config that lets the pad
work but not the nib:

CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1600
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1200
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_INPUT_UINPUT=y
CONFIG_BUSMOUSE=y
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
CONFIG_USB_DEVICEFS=y
CONFIG_USB_LONG_TIMEOUT=y
# CONFIG_USB_BANDWIDTH is not set
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_UHCI_HCD_ALT=m
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_POWERMATE=m
CONFIG_USB_XPAD=m

-JimC