linuxconsole-dev

Re: [linux-fbdev] New api again

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

On Tue, 16 Jan 2001, Pete Zaitcev wrote:

> >     Since 2.4 is now out and the new console system is becoming stable its
> > time to discuss the new api for fbcon again. I updated skeletonfb for a
> > example and posted here. Feel free to addd input to the design.
> 
> Would you provide an executive summary of undelying reasons
> for the changes? For instance, "To remove race conditions
> inherent in the old API around functions such-and-such",
> or "to reduce complexity implementing feature this-and-athat".
> I cannot easily understand what you are trying to accomplish.

The main reason was to remove all the console related stuff of the 
fbdev drivers. The reasons for this was:

1) If changes or important bug fixes where to happen to the higher fbcon
   layers every fbdev driver would have to be changed. With the new api
   if changes happen to fbcon.c and friends we don't have to rewrite every
   fbdev driver.	

2) Make driver developement easier.

3) Alot of the console code in each fbdev driver is basically the same. So
   we have huge amounts of code duplication. 

Re: [linux-fbdev] New api again

[Takashi Oe <to...@un...>]

On 1/16/01 1:23 PM, James Simmons wrote:

> 
> Hi folks!!
> 
> Since 2.4 is now out and the new console system is becoming stable its
> time to discuss the new api for fbcon again. I updated skeletonfb for a
> example and posted here. Feel free to addd input to the design.

[...]
> /*
> *  Set a single color register. The values supplied have a 16 bit
> *  magnitude. Return != 0 for invalid regno. This routine assumes
> *  your graphics hardware is packed pixel based (most are :-).
> *  Return != 0 for invalid regno.
> */
> static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
> unsigned blue, unsigned transp,
> const struct fb_info *info)

Could there be a multiple color version as well?  For 2.4, I have my own
fb_set_cmap to do that since a cmap access requires a synchronization with
vsync for the first one on my machine, and I don't want to do the
synchronization for every cmap change.

Want to do:
- vsync
- multiple cmap change
rather than:
- vsync
- a cmap change
- vsync
- a cmap change
- ....

If there is a way to override fb_set_cmap (or a new api's equivalent)
calling setcolreg, that would be okay, too.

[...]
> info.pseudo_palette = xxxfb_pseudo_palette;

How is this psuedo_palette used for new api?


Takashi Oe

Re: [linux-fbdev] New api again

[Pete Z. <za...@me...>]

>     Since 2.4 is now out and the new console system is becoming stable its
> time to discuss the new api for fbcon again. I updated skeletonfb for a
> example and posted here. Feel free to addd input to the design.

Would you provide an executive summary of undelying reasons
for the changes? For instance, "To remove race conditions
inherent in the old API around functions such-and-such",
or "to reduce complexity implementing feature this-and-athat".
I cannot easily understand what you are trying to accomplish.

-- Pete

inputattach on sa1100

[Justin C. <jp...@do...>]

Trying to get the input drivers working on Arm (sa1100), and having
problems with inputattach. First is that it isnt dropping RTS to reset
the devices. Someone else is working on that - it doesnt matter for all
devices anyway. However I am getting a failure in

        devt = SERIO_RS232 | input_types[type].type | (input_types[type].extra << 16);

        if(ioctl(fd, SPIOCSTYPE, &devt)) {
                fprintf(stderr, "inputattach: can't set device type\n");
                return 1;
        }

basically the ioctl seems to fail, which is from serport.c:

static int serport_ldisc_ioctl(struct tty_struct * tty, struct file * file, unsigned int cmd, unsigned long arg)
{
        struct serport *serport = (struct serport*) tty->disc_data;
        
        switch (cmd) {
                case SPIOCSTYPE:
                        return get_user(serport->serio.type, (unsigned long *) arg);
        }

        return -EINVAL;
}

Any idea whats wrong here? The cast looks a little odd to me. But I dont really
know my way around this code very well yet...

Justin

New api again

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

Hi folks!!

    Since 2.4 is now out and the new console system is becoming stable its
time to discuss the new api for fbcon again. I updated skeletonfb for a
example and posted here. Feel free to addd input to the design.

/*
 * linux/drivers/video/skeletonfb.c -- Skeleton for a frame buffer device
 *
 *  Modified to new api Jan 2001 by James Simmons (jsi...@li...)
 *
 *  Created 28 Dec 1997 by Geert Uytterhoeven
 *
 * This file is subject to the terms and conditions of the GNU General Public
 * License.  See the file COPYING in the main directory of this archive
 * for more details.
 */

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/tty.h>
#include <linux/malloc.h>
#include <linux/delay.h>
#include <linux/fb.h>
#include <linux/init.h>

/* This header contains struct xxx_par for your graphics card */
#include <video/skeletion.h>

    /*
     *  This is just simple sample code.
     *
     *  No warranty that it actually compiles.
     *  Even less warranty that it actually works :-)
     */

static struct fb_fix_screeninfo xxxfb_fix __initdata = {
    "FB's name", (unsigned long) NULL, 0, FB_TYPE_PACKED_PIXELS, 0,
    FB_VISUAL_PSEUDOCOLOR, 1, 1, 1, 0, (unsigned long) NULL, 0, FB_ACCEL_NONE
};

    /*
     * 	Modern graphical hardware not only supports pipelines but some 
     *  also support multiple monitors where each display can have its  
     *  its own unique data. In this case each display could be  
     *  represented by a seperate framebuffer device thus a seperate 
     *  struct fb_info. In this case all of the par structures for the
     *  graphics card would be shared between each struct fb_info. This
     *  allows when one display changes it video resolution (info->var) 
     *  the other displays know instantly. Each display can always be
     *  aware of the entire hardware state that affects it. I hope this 
     *  covers every possible hardware design. If not feel free to send 
     *  me more design types. 
     */

    /*
     *  If your driver supports multiple boards, you should make these  
     *  arrays, or allocate them dynamically (using kmalloc()). 
     */ 
static struct fb_info info;
    /* 
     * This struct represents the state of a rendering pipe. A modern 
     * graphics card can have more than one pipe per card depending 
     * on the hardware design. So the same holds true if you have
     * multiple pipes. Use arrays or allocate them dynamically.
     *
     * Read video/skeleton.h for more information about graphics pipes. 
     */
static struct xxx_par __initdata current_par;

static u32 xxxfb_pseudo_palette[17];
static int inverse = 0;

int xxxfb_init(void);
int xxxfb_setup(char*);

/* ------------------- chipset specific functions -------------------------- */

static int xxxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
    const struct xxx_par *par = (const struct xxx_par *) info->par;
    /* 
     * We test to see if the hardware can support var. Struct xxx_par will
     * have the information needed to see if it does. Note we don't change
     * par nor info->var. This function can be called on its own if we
     * intent to only test a mode and not set it. Return 0 if it is a
     * acceptable mode.
     */

    /* ... */
    return 0;	   	
}

static void xxxfb_set_par(struct fb_info *info)
{
    /*
     *  xxx_fb_check_var tested the mode we want to set the hardware to.
     *  If it passes it then is set to info->var. Now we set the hardware
     *  (and struct par) according to info->var.
     */

    /* ... */
}

    /*
     *  Set a single color register. The values supplied have a 16 bit
     *  magnitude. Return != 0 for invalid regno. This routine assumes
     *  your graphics hardware is packed pixel based (most are :-). 
     *  Return != 0 for invalid regno.
     */
static int xxxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
			   unsigned blue, unsigned transp,
			   const struct fb_info *info)
{
    if (regno >= 256)  /* no. of hw registers */
       return 1;
    /*
     * Program hardware... do anything you want with transp
     */

    /* grayscale works only partially under directcolor */
    if (info->var.grayscale) {
       /* grayscale = 0.30*R + 0.59*G + 0.11*B */
       red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
    }

    /* Directcolor:
     *   var->{color}.offset contains start of bitfield
     *   var->{color}.length contains length of bitfield
     *   {hardwarespecific} contains width of DAC
     *   cmap[X] is programmed to (X << red.offset) | (X << green.offset) | (X << blue.offset)
     *   DAC[X] is programmed to (red, green, blue)
     *
     * Pseudocolor:
     *    uses offset = 0 && length = DAC register width.
     *    var->{color}.offset is 0
     *    var->{color}.length contains widht of DAC
     *    cmap is not used
     *    DAC[X] is programmed to (red, green, blue)
     * Truecolor:
     *    does not use DAC.
     *    var->{color}.offset contains start of bitfield
     *    var->{color}.length contains length of bitfield
     *    cmap is programmed to (red << red.offset) | (green << green.offset) |
     *                      (blue << blue.offset) | (transp << transp.offset)
     *    DAC does not exist
     */
#define CNVT_TOHW(val,width) ((((val)<<(width))+0x7FFF-(val))>>16)
    switch (info->fix.visual) {
       case FB_VISUAL_TRUECOLOR:
       case FB_VISUAL_PSEUDOCOLOR:
               red = CNVT_TOHW(red, info->var.red.length);
               green = CNVT_TOHW(green, info->var.green.length);
               blue = CNVT_TOHW(blue, info->var.blue.length);
               transp = CNVT_TOHW(transp, info->var.transp.length);
               break;
       case FB_VISUAL_DIRECTCOLOR:
	       /* example here assumes 8 bit DAC. Might be different 
		* for your hardware */	
               red = CNVT_TOHW(red, 8);       
               green = CNVT_TOHW(green, 8);
               blue = CNVT_TOHW(blue, 8);
               /* hey, there is bug in transp handling... */
               transp = CNVT_TOHW(transp, 8);
               break;
    }
#undef CNVT_TOHW
    /* Truecolor has hardware independent palette */
    if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
       u32 v;

       if (regno >= 16)
           return 1;

       v = (red << info->var.red.offset) |
           (green << info->var.green.offset) |
           (blue << info->var.blue.offset) |
           (transp << info->var.transp.offset);
       if (info->var.bits_per_pixel == 16)
           ((u16*)(info->pseudo_palette))[regno] = v;
       else
           ((u32*)(info->pseudo_palette))[regno] = v;
       return 0;
    }
    /* ... */
    return 0;
}

static int xxxfb_pan_display(struct fb_var_screeninfo *var,
			     const struct fb_info *info)
{
    /*
     *  Pan (or wrap, depending on the `vmode' field) the display using the
     *  `xoffset' and `yoffset' fields of the `var' structure.
     *  If the values don't fit, return -EINVAL.
     */

    /* ... */
    return 0;
}

static int xxxfb_blank(int blank_mode, const struct fb_info *info)
{
    /*
     *  Blank the screen if blank_mode != 0, else unblank. If blank == NULL
     *  then the caller blanks by setting the CLUT (Color Look Up Table) to all
     *  black. Return 0 if blanking succeeded, != 0 if un-/blanking failed due
     *  to e.g. a video mode which doesn't support it. Implements VESA suspend
     *  and powerdown modes on hardware that supports disabling hsync/vsync:
     *    blank_mode == 2: suspend vsync
     *    blank_mode == 3: suspend hsync
     *    blank_mode == 4: powerdown
     */

    /* ... */
    return 0;
}

/* ------------ Accelerated Functions --------------------- */

/*
 * We provide our own functions if we have hardware acceleration
 * or non packed pixel format layouts.  
 */

void xxxfb_rectfill(struct fb_info *p, int x1, int y1, unsigned int width,
                    unsigned int height, unsigned long color, int rop)
{
}

void xxxfb_copyarea(struct fb_info *p, int sx, int sy, unsigned int width,
                         unsigned int height, int dx, int dy)
{
}

void xxxfb_imageblit(struct fb_info *p, unsigned int width,
                     unsigned int height, unsigned long *image,
                     int image_depth, int dx, int dy)
{
}

/* ------------ Hardware Independent Functions ------------ */

    /*
     *  Initialization
     */

int __init xxxfb_init(void)
{
    int retval;	
   
    /* 
     * Here we set the screen_base to the vitrual memory address
     * for the framebuffer. Usually we obtain the resource address
     * from the bus layer and then translate it to virtual memory
     * space via ioremap. Consult ioport.h. 
     */
    info.screen_base = framebuffer_virtual_memory;	
    info.node = -1;
    info.fbops = &xxxfb_ops;
    info.fix = xxxfb_fix;
    info.par = xxx_par;
    info.pseudo_palette = xxxfb_pseudo_palette;
    info.flags = FBINFO_FLAG_DEFAULT;
    /* This should give a reasonable default video mode */
    if (!mode_option)
	mode_option = "640x480@60";	 	

    retval = fb_find_mode(&info.var, &info, mode_option, NULL, 0, NULL, 8);
  
    if (!retval || retval == 4)
	return -EINVAL;			

    info.cmap = fb_default_cmap(1<<info.var.bits_per_pixel);	
	
    if (register_framebuffer(&info) < 0)
	return -EINVAL;
    printk(KERN_INFO "fb%d: %s frame buffer device\n", GET_FB_IDX(info.node),
	   info.fix.id);

    /* uncomment this if your driver cannot be unloaded */
    /* MOD_INC_USE_COUNT; */
    return 0;
}

    /*
     *  Cleanup
     */

void xxxfb_cleanup(struct fb_info *info)
{
    /*
     *  If your driver supports multiple boards, you should unregister and
     *  clean up all instances.
     */

    unregister_framebuffer(info);
    /* ... */
}


    /*
     *  Setup
     */

int __init xxxfb_setup(char *options)
{
    /* Parse user speficied options (`video=xxxfb:') */
}


/* ------------------------------------------------------------------------- */

    /*
     *  Frame buffer operations
     */

/* If all you need is that - just don't define ->fb_open */
static int xxxfb_open(const struct fb_info *info, int user)
{
    return 0;
}

/* If all you need is that - just don't define ->fb_release */
static int xxxfb_release(const struct fb_info *info, int user)
{
    return 0;
}

static struct fb_ops xxxfb_ops = {
	owner:		THIS_MODULE,
	fb_open:	xxxfb_open,    /* only if you need it to do something */
	fb_release:	xxxfb_release, /* only if you need it to do something */
	fb_check_var:	xxxfb_check_var,
	fb_set_par:	xxxfb_set_par,
	fb_setcolreg:	xxxfb_setcolreg,
	fb_blank:	xxxfb_blank,
	fb_pan_display:	xxxfb_pan_display,
	fb_rectfill:	xxxfb_rectfill,  /* optional */
	fb_copyarea:	xxxfb_copyarea,  /* optional */
	fb_imageblit:	xxxfb_imageblit, /* optional */
	fb_ioctl:       xxxfb_ioctl,     /* optional */
	fb_mmap:	xxxfb_mmap,      /* optional */	
};

/* ------------------------------------------------------------------------- */


    /*
     *  Modularization
     */

#ifdef MODULE
int init_module(void)
{
    return xxxfb_init();
}

void cleanup_module(void)
{
    xxxfb_cleanup(void);
}
#endif /* MODULE */





/*
 * linux/include/video/skeletonfb.h -- example graphics header. See other
 *				       files in that directory. 
 *
 *  Copyright 2001 James Simmons (jsi...@li...)
 *
 * This files is designed to be independent of the fbdev layer. This header
 * is provided so userland applications can have a standard set of headers
 * to program graphics hardware with as well as other kernel subsystems
 * that need to program the video hardware. 
 *
 * This file is subject to the terms and conditions of the GNU General Public
 * License.  See the file COPYING in the main directory of this archive
 * for more details.
 *
 */

struct xxx_par {
    /*
     *  The hardware specific data in this structure uniquely defines a
     *  graphics card pipe's state. What is a graphics pipe and a
     *  graphics pipeline ? The automotive assembly line is a classic
     *  example of a pipeline. Each car goes through a series of stages
     *  on its way to the exit gates. At any given time many cars could
     *  be in some stage of completion. Each stage is know as a pipe.
     *  Rendering can also function in the same way. For rendering each
     *  stage must be performed in a specific order but each stage itself
     *  can operate independent of the previous stage because each stage
     *  stage can operate on a different set of data sent to the graphics
     *  card. This allows several rendering operations to occur at the
     *  same time.
     *
     *  Todays hardware comes in a variety of setups. With this variety
     *  comes different ways pipes can exist. Most low end graphical
     *  cards lack a graphics pipeline. It can be thought of as a
     *  assembly line with only one car allowed on it at a time. Some
     *  hardware exist where the cards have more than one GPU (graphical
     *  processing unit). If each GPU can have different hardware states
     *  that are independent of each other then each CPU has a single
     *  pipe and they can work as a pipeline. Also their exist hardware
     *  where you can chain video cards together and feed them to one
     *  display device. Here each video card acts as a seperate pipe
     *  and we can achieve a pipeline effect. Be aware it might be
     *  possible to disable and enable individual pipes.
     */
};

Re: atkbd patch

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

Patches applied :-) Also tested and they work fine.

Re: Compiling 2.4.0 with ruby revisited.

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

> I've got this error on compile now, when enabling the NVidia hardware
> text console:
> (I've got a GeForce 2 to try out...)

Sorry I haven't got around to updating this driver. Will work on it today. 

Compiling 2.4.0 with ruby revisited.

[Adam H. <sv...@ea...>]

I've got this error on compile now, when enabling the NVidia hardware
text console:
(I've got a GeForce 2 to try out=2E=2E=2E)

gcc -D__KERNEL__ -I/SDA3/usr/src/linux_patched/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -
fno-strict-aliasing -pipe -mpreferred-stack-boundary=3D2 -march=3Di686    -c
-o nvvgacon=2Eo nvvgacon=2Ec
nvvgacon=2Ec:799: warning: initialization from incompatible pointer type
nvvgacon=2Ec:801: unknown field `con_switch' specified in initializer
nvvgacon=2Ec:801: warning: initialization from incompatible pointer type
nvvgacon=2Ec:802: duplicate initializer
nvvgacon=2Ec:802: (near initialization for `nvvga_con=2Econ_blank')
nvvgacon=2Ec:805: unknown field `con_scrolldelta' specified in initializer
nvvgacon=2Ec:805: duplicate initializer
nvvgacon=2Ec:805: (near initialization for `nvvga_con=2Econ_scroll')
nvvgacon=2Ec: In function `nvvga_console_init':
nvvgacon=2Ec:845: structure has no member named `vcs'
nvvgacon=2Ec:853: structure has no member named `vcs'
nvvgacon=2Ec: At top level:
nvvgacon=2Ec:98: warning: `vram' defined but not used
make[4]: *** [nvvgacon=2Eo] Error 1
make[4]: Leaving directory `/SDA3/usr/src/linux_patched/drivers/video'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory `/SDA3/usr/src/linux_patched/drivers/video'
make[2]: *** [_subdir_video] Error 2
make[2]: Leaving directory `/SDA3/usr/src/linux_patched/drivers'
make[1]: *** [_dir_drivers] Error 2
make[1]: Leaving directory `/SDA3/usr/src/linux_patched'
make: *** [stamp-build] Error 2

What gives?

Cheers,
--=20
Adam Huuva / Easter-eggs                 Sp=E9cialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  M=E9tro Gait=E9
Phone: +33 (0) 1 43 35 00 37    -   Fax: +33 (0) 1 41 35 00 76
mailto:sventon@easter-eggs=2Ecom  -   http://www=2Eeaster-eggs=2Ecom

Re: Newton keyboard driver

[Justin C. <jp...@do...>]

Sorry, no, just the keyboard working. I dont have a Newton, but I suspect
you wont get Linux running on it, though I dont know the spec.


Justin



> 
> On Sun, Jan 14, 2001 at 05:48:49PM +0000, Justin Cormack wrote:
> > ok, here's a ruby patch to add a Newton keyboard driver. It is a nice 
> > portable serial keyboard that Apple sold may years back. If noone has
> > any suggestions for changes I'll submit it to 2.4 as well. The only
> > thing about 2.4 is that serio.c is in drivers/char/joystick and this
> > will go into drivers/char: serio really ought to move to char, as it is
> > not joystick specific.
> 
> Are you telling me that you have Linux running on a Newton?  That would
> be really cool since our hospital happens to have about 100 of them
> stashed away in the cellar...
> 
> Dominik
> 

Newton keyboard driver

[Justin C. <jp...@do...>]

ok, here's a ruby patch to add a Newton keyboard driver. It is a nice 
portable serial keyboard that Apple sold may years back. If noone has
any suggestions for changes I'll submit it to 2.4 as well. The only
thing about 2.4 is that serio.c is in drivers/char/joystick and this
will go into drivers/char: serio really ought to move to char, as it is
not joystick specific.

Justin

diff -u -r -N ruby-orig/linux/drivers/input/Config.in ruby/linux/drivers/input/Config.in
--- ruby-orig/linux/drivers/input/Config.in     Sat Nov 11 12:37:01 2000
+++ ruby/linux/drivers/input/Config.in  Sun Jan 14 17:09:14 2001
@@ -37,6 +37,7 @@
       tristate '  Gravis Stinger gamepad' CONFIG_INPUT_STINGER
       tristate '  I-Force joysticks/wheels' CONFIG_INPUT_IFORCE_232
       tristate '  Gunze AHL-51S touchscreen' CONFIG_INPUT_GUNZE
+      tristate '  Newton keyboard' CONFIG_INPUT_NEWTON
    fi
    
    bool 'Standard Game port support' CONFIG_INPUT_GAMEPORT
diff -u -r -N ruby-orig/linux/drivers/input/Makefile ruby/linux/drivers/input/Makefile
--- ruby-orig/linux/drivers/input/Makefile      Sat Nov 11 12:37:01 2000
+++ ruby/linux/drivers/input/Makefile   Sun Jan 14 17:09:14 2001
@@ -50,6 +50,7 @@
 obj-$(CONFIG_INPUT_ATKBD)      += atkbd.o serio.o
 obj-$(CONFIG_INPUT_XTKBD)      += xtkbd.o serio.o
 obj-$(CONFIG_INPUT_PSMOUSE)    += psmouse.o serio.o
+obj-$(CONFIG_INPUT_NEWTON)     += newtonkbd.o serio.o
 
 obj-$(CONFIG_INPUT_SERMOUSE)   += sermouse.o serio.o
 obj-$(CONFIG_INPUT_SUNKBD)     += sunkbd.o serio.o
diff -u -r -N ruby-orig/linux/drivers/input/newtonkbd.c ruby/linux/drivers/input/newtonkbd.c
--- ruby-orig/linux/drivers/input/newtonkbd.c   Thu Jan  1 01:00:00 1970
+++ ruby/linux/drivers/input/newtonkbd.c        Sun Jan 14 17:32:20 2001
@@ -0,0 +1,152 @@
+/*
+ *
+ *
+ *  Copyright (c) 2000 Justin Cormack
+ *
+ *
+ */
+
+/*
+ * Newton keyboard driver for Linux
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or 
+ * (at your option) any later version.
+ * 
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ * 
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * 
+ * Should you need to contact me, the author, you can do so either by
+ * e-mail - mail your message to <j.c...@do...>, or by paper mail:
+ * Justin Cormack, 68 Dartmouth Park Road, London NW5 1SN, UK.
+ */
+
+#include <linux/malloc.h>
+#include <linux/module.h>
+#include <linux/input.h>
+#include <linux/init.h>
+#include <linux/serio.h>
+
+MODULE_AUTHOR("Justin Cormack <j.c...@do...>");
+
+#define NKBD_KEY       0x7f
+#define NKBD_PRESS     0x80
+
+static unsigned char nkbd_keycode[128] = {      
+  KEY_A, KEY_S, KEY_D, KEY_F, KEY_H, KEY_G, KEY_Z, KEY_X,
+  KEY_C, KEY_V, 0, KEY_B, KEY_Q, KEY_W, KEY_E, KEY_R,
+  KEY_Y, KEY_T, KEY_1, KEY_2, KEY_3, KEY_4, KEY_6, KEY_5,
+  KEY_EQUAL, KEY_9, KEY_7, KEY_MINUS, KEY_8, KEY_0, KEY_RIGHTBRACE, KEY_O,
+  KEY_U, KEY_LEFTBRACE, KEY_I, KEY_P, KEY_ENTER, KEY_L, KEY_J, KEY_APOSTROPHE,
+  KEY_K, KEY_SEMICOLON, KEY_BACKSLASH, KEY_COMMA, KEY_SLASH, KEY_N, KEY_M, KEY_DOT,
+  KEY_TAB, KEY_SPACE, KEY_GRAVE, KEY_DELETE, 0, 0, 0, KEY_LEFTMETA,
+  KEY_LEFTSHIFT, KEY_CAPSLOCK, KEY_LEFTALT, KEY_LEFTCTRL, KEY_RIGHTSHIFT, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, 0, 0, 0, 0, 0,
+  0, 0, 0, KEY_LEFT, KEY_RIGHT, KEY_DOWN, KEY_UP, 0
+};
+
+static char *nkbd_name = "Newton Keyboard";
+
+struct nkbd {
+  unsigned char keycode[128];
+  struct input_dev dev;
+  struct serio *serio;
+};
+
+void nkbd_interrupt(struct serio *serio, unsigned char data, unsigned int flags)
+{
+  struct nkbd *nkbd = serio->private;
+
+  /* invalid scan codes are probably the init sequence, so we ignore them */
+  if (nkbd->keycode[data & NKBD_KEY])
+    input_report_key(&nkbd->dev, nkbd->keycode[data & NKBD_KEY], data & NKBD_PRESS);
+  else if (data == 0xe7) /* end of init sequence */ 
+    printk(KERN_INFO "input%d: %s on serio%d\n", nkbd->dev.number, nkbd_name, serio->number);
+
+}

+
+void nkbd_connect(struct serio *serio, struct serio_dev *dev)
+{
+       struct nkbd *nkbd;
+       int i;
+
+       if (serio->type != (SERIO_RS232 | SERIO_NEWTON))
+         return;
+
+       if (!(nkbd = kmalloc(sizeof(struct nkbd), GFP_KERNEL)))
+         return;
+
+       memset(nkbd, 0, sizeof(struct nkbd));
+       
+       nkbd->dev.evbit[0] = BIT(EV_KEY) | BIT(EV_REP);
+
+       nkbd->serio = serio;
+
+       nkbd->dev.keycode = nkbd->keycode;
+       nkbd->dev.private = nkbd;
+
+       serio->private = nkbd;
+



+       if (serio_open(serio, dev)) {
+               kfree(nkbd);
+               return;
+       }
+
+       memcpy(nkbd->keycode, nkbd_keycode, sizeof(nkbd->keycode));
+       for (i = 0; i < 128; i++)
+               set_bit(nkbd->keycode[i], nkbd->dev.keybit);
+       clear_bit(0, nkbd->dev.keybit);
+
+       nkbd->dev.name = nkbd_name;
+       nkbd->dev.idbus = BUS_RS232;
+       nkbd->dev.idvendor = SERIO_NEWTON;
+       nkbd->dev.idproduct = 0x0001;
+       nkbd->dev.idversion = 0x0100;
+
+       input_register_device(&nkbd->dev);
+
+       printk(KERN_INFO "input%d: %s on serio%d\n", nkbd->dev.number, nkbd_name, serio->number);
+}
+
+void nkbd_disconnect(struct serio *serio)




+{
+       struct nkbd *nkbd = serio->private;
+       input_unregister_device(&nkbd->dev);
+       serio_close(serio);
+       kfree(nkbd);
+}
+
+struct serio_dev nkbd_dev = {
+       interrupt:      nkbd_interrupt,
+       connect:        nkbd_connect,
+       disconnect:     nkbd_disconnect
+};
+
+int __init nkbd_init(void)
+{
+       serio_register_device(&nkbd_dev);
+       return 0;
+}
+
+void __exit nkbd_exit(void)
+{
+       serio_unregister_device(&nkbd_dev);
+}
+
+module_init(nkbd_init);
+module_exit(nkbd_exit);
diff -u -r -N ruby-orig/linux/include/linux/serio.h ruby/linux/include/linux/serio.h
--- ruby-orig/linux/include/linux/serio.h       Mon Jul 17 11:42:14 2000
+++ ruby/linux/include/linux/serio.h    Sun Jan 14 17:09:14 2001
@@ -104,6 +104,7 @@
 #define SERIO_GUNZE    0x1c
 #define SERIO_IFORCE   0x1d
 #define SERIO_STINGER  0x1e
+#define SERIO_NEWTON    0x1f
 
 #define SERIO_ID       0xff00UL
 #define SERIO_EXTRA    0xff0000UL
diff -u -r -N ruby-orig/utils/inputattach.c ruby/utils/inputattach.c
--- ruby-orig/utils/inputattach.c       Mon Jul 17 11:42:15 2000
+++ ruby/utils/inputattach.c    Sun Jan 14 17:09:14 2001
@@ -147,6 +147,24 @@
        return 0;
 }
 
+int newton_init(int fd)
+{
+  int i;
+  unsigned char c;
+  unsigned char response[35] =
+  { 0x16, 0x10, 0x02, 0x64, 0x5f, 0x69, 0x64, 0x00,
+    0x00, 0x00, 0x0c, 0x6b, 0x79, 0x62, 0x64, 0x61,
+    0x70, 0x70, 0x6c, 0x00, 0x00, 0x00, 0x01, 0x6e,
+    0x6f, 0x66, 0x6d, 0x00, 0x00, 0x00, 0x00, 0x10,
+    0x03, 0xdd, 0xe7 };
+
+  for (i = 0; i < 35; i++)
+    if (readchar(fd, &c, 400) || (c != response[i]))
+      return -1;
+
+  return 0; 
+}
+
 int dump_init(int fd)
 {
        unsigned char c, o = 0;
@@ -190,6 +208,7 @@
 { "--intellimouse",    "-ms3",         B1200, CS7,                     SERIO_MZ,       0x11,   1,      NULL },
+  for (i = 0; i < 35; i++)
+    if (readchar(fd, &c, 400) || (c != response[i]))
+      return -1;
+
+  return 0; 
+}
+
 int dump_init(int fd)
 {
        unsigned char c, o = 0;
@@ -190,6 +208,7 @@
 { "--intellimouse",    "-ms3",         B1200, CS7,                     SERIO_MZ,       0x11,   1,      NULL },
 { "--mmwheel",         "-mmw",         B1200, CS7 | CSTOPB,            SERIO_MZP,      0x13,   1,      mzp_init },
 { "--iforce",          "-ifor",        B38400, CS8 | CRTSCTS,          SERIO_IFORCE,   0x00,   0,      NULL },
+{ "--newtonkbd",        "-newt",        B9600, CS8,                     SERIO_NEWTON,  0x00,   0,      newton_init },
 { "--dump",            "-dump",        B1200, CS7,                     0,              0x00,   0,      dump_init },
 { "", "", 0, 0 }
 

atkbd patch

[Justin C. <jp...@do...>]

Here is a small patch for atkbd.c, which removes the compile warnings and adds my laptops keyboard.

Justin

--- drivers/input/atkbd.c	Mon Dec 11 15:55:45 2000
+++ /usr/src/linux-2.4.0-ruby/drivers/input/atkbd.c	Sun Jan 14 12:31:12 2001@@ -127,7 +127,7 @@
 	char ack;
 	char emul;
 	char error;
-	short id;
+	unsigned short id;
 };
 
 /*
@@ -356,7 +356,8 @@
 /*
  * Next, we check if it's a keyboard. It should send 0xab83
  * (0xab84 on IBM ThinkPad, and 0xaca1 on a NCD Sun layout keyboard,
- * 0xab02 on unxlated i8042 and 0xab03 on unxlated ThinkPad).
+ * 0xab02 on unxlated i8042 and 0xab03 on unxlated ThinkPad, 0xab7f
+ * on Fujitsu Lifebook).
  * If it's a mouse, it'll only send 0x00 (0x03 if it's MS mouse),
  * and we'll time out here, and report an error.
  */
@@ -369,7 +370,7 @@
 	atkbd->id = (param[0] << 8) | param[1];
 
 	if (atkbd->id != 0xab83 && atkbd->id != 0xab84 && atkbd->id != 0xaca1 &&-	    atkbd->id != 0xab02 && atkbd->id != 0xab03)
+	    atkbd->id != 0xab7f && atkbd->id != 0xab02 && atkbd->id != 0xab03)
 		printk(KERN_WARNING "atkbd.c: Unusual keyboard ID: %#x\n", atkbd->id);
 
 	return 0;

Re: writing a keyboard driver

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

> I am just sitting down to write a kernel module for an Apple Newton serial
> keyboard,a nd I am slightly confused by the terminology about scancodes.
> 
> 1.7 The keycode, keycodemax, keycodesize fields
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> These two fields will be used for any inpur devices that report their data
> as scancodes. If not all scancodes can be known by autodetection, they may
> need to be set by userland utilities. The keycode array then is an array
> used to map from scancodes to input system keycodes. The keycode max will
> contain the size of the array and keycodesize the size of each entry in it
> (in bytes).

Scancodes are what are generated by the hardware. If you press a 7 on
say a alpha you might get a code from hardware of say 34. On a PC you
get a value of 117. The input system has a bunch of defined values for
specific keys. So if you are reading /dev/eventX and you get KEY_7 this
means you press a 7 no matter what the value was the hardware generated. 
Each input driver has a keycode array to perform this mapping which
basically goes from hardware specific codes to universal
codes. keycode_max is the size of the array which is the maximum number of 
keys that can generate codes times what the size of the each field 
(keycodesize).  

writing a keyboard driver

[Justin C. <jp...@do...>]

I am just sitting down to write a kernel module for an Apple Newton serial
keyboard,a nd I am slightly confused by the terminology about scancodes.

1.7 The keycode, keycodemax, keycodesize fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These two fields will be used for any inpur devices that report their data
as scancodes. If not all scancodes can be known by autodetection, they may
need to be set by userland utilities. The keycode array then is an array
used to map from scancodes to input system keycodes. The keycode max will
contain the size of the array and keycodesize the size of each entry in it
(in bytes).

What does this actually mean? Should I use this? Could someone just quickly
explain...


Justin

Re: Compiling 2.4.0 with ruby.

[Adam H. <sv...@ea...>]

James Simmons wrote:
>=20
> > Now I've got a kernel that boots, but no input devices/console at
> > all=2E=2E=2E heh=2E Why is this?=20
>=20
> Where exactly? Do you get about here and it stops:
>=20
> Detected 497=2E841 MHz processor=2E
> Console: colour VGA+ 80x25
>=20
It works now=2E I hadn't added the i8042 controller in the kernel
config=2E

Cheers,
--=20
Adam Huuva / Easter-eggs                 Sp=E9cialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  M=E9tro Gait=E9
Phone: +33 (0) 1 43 35 00 37    -   Fax: +33 (0) 1 41 35 00 76
mailto:sventon@easter-eggs=2Ecom  -   http://www=2Eeaster-eggs=2Ecom

Re: Compiling 2.4.0 with ruby.

[Petr V. <VAN...@vc...>]

On 11 Jan 01 at 10:06, James Simmons wrote:

> > > don't see multiple video cards so only the first one on the PCI bus gets
> > > intialized :-(
> > 
> > So not yet. But would the bios still initialize all heads on a multihead
> > card? No, I guess not, just the first. A job for linuxbios? :)
> 
> If you mean by multihead card a single video card that supports more than
> one monitor than no. That would be up to the driver to program both heads.

Matrox G450 BIOS initializes both outputs. And put same picture on both...
So even with vgacon you'll get two same outputs.

> You still need to initialze the card with the BIOS if you don't know what
> regitser specs are needed to initialize the video card. A good example is
> the matrox framebuffer driver for this which BTW is BIOS independent :-)

Unfortunately not for G450 and not always for G100 and G400... I have to
find how SGRAM have to be initialized... And for G400/G450 how to find
whether connected memory is 3V TTL or CMOS SDRAM/SGRAM, or xxxV DDRAM...
If someone has code which can autodetect SDRAM/SGRAM, or which
can autodetect DRAM page size... Otherwise I have to parse MGA BIOS,
as XFree does. And it is tricky on Gx00 multimonitor devices - they
have 4 Gx00 cores, but only one of them has BIOS connected...
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...

Re: splitting ruby

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

> I'd also favor the partially merge.
> IMHO the following order is best:
> 
> 1) move the busmouse code (excluding ps2, because it is more difficult)
>    over to input in 2.5.<veryearly> and merge the serial mouse code.
> 2) move over the other input drivers to new-style input code.  This
>    will include Martin's old version of keyboard.c for the input drivers.

Yeap. That sounds about right.

> 3) merge the new console code.  If possible in smaller chunks, because
>    Linus likes that.

First we need to change the fbdev drivers to the new api. Then we can
change the fbcon layer with ease.

Re: Compiling 2.4.0 with ruby.

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

> Now I've got a kernel that boots, but no input devices/console at
> all... heh. Why is this? I have configured the kernel for ps/2 in 'Input
> device support' and chosen 
> 'AT and PS/2 keyboards' and 'PS/2 mouse' in PS/2 port input devices.
> What more do I need to do?

Where exactly? Do you get about here and it stops:

Detected 497.841 MHz processor.
Console: colour VGA+ 80x25

Or did you compile in the AT keyboard support or is it modular. I found it
is much safer to compile support in. 
 
> Not that I have several sets of keyboards/mice yet. I've got one set
> (PS/2), I'll be testing with a USB keyboard shortly I believe.

I have these as well and they work :-) Note I just started working on
fbcon support so only vgacon/mdacon works right now. Do you have a NVIDIA
card. We have a driver for that as well. Another thing to point out is for
a functioning VT you need one keyboard and one display. Using /dev/event
you can access any keyboard, attached or not attached to a VT.

Re: Compiling 2.4.0 with ruby.

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

> > Try the lastest CVS. It is fixed.
> OK. It is. Now I have this instead:
> 
> In file included from
> /SDA3/usr/src/linux_patched/include/linux/irq.h:57,

This is a problem with the standard kernel which our tree is against ;-(

> dummycon.c: At top level:
> dummycon.c:64: unknown field `con_switch' specified in initializer
> dummycon.c:65: duplicate initializer
> dummycon.c:65: (near initialization for `dummy_con.con_blank')
> dummycon.c:69: unknown field `con_scrolldelta' specified in initializer
> dummycon.c:69: duplicate initializer
> dummycon.c:69: (near initialization for `dummy_con.con_scroll')
> make[4]: *** [dummycon.o] Error 1

Fixed and commited.

> > Not yet. This requires rewriting the fbcon layer which I'm about to do.
> 
> So I can't run several vgacons on different graphics cards/chips yet
> either?

Well with vga ISA hardware it is much more difficult to do. Some cards
allowed for you to change the register space but very few allow you to
change the memory region that vga uses (a000). 

> Due to the bios restriction?

Most video cards depend on some code in their firmware to initialize their
hardware to run. This is why if you can't buy say a Voodoo video card for
the mac and plug it into a PC. Vice verse is also true. What is needed is
to figure out which registers the video card needs programmed that the
firware does. This would then allow the driver to be truly platform
independent. On PCs the BIOS is needed to intialize the video
card. Unfortunely they don't initialize more than one.

> > don't see multiple video cards so only the first one on the PCI bus gets
> > intialized :-(
> 
> So not yet. But would the bios still initialize all heads on a multihead
> card? No, I guess not, just the first. A job for linuxbios? :)

If you mean by multihead card a single video card that supports more than
one monitor than no. That would be up to the driver to program both heads.
You still need to initialze the card with the BIOS if you don't know what
regitser specs are needed to initialize the video card. A good example is
the matrox framebuffer driver for this which BTW is BIOS independent :-)

Re: Compiling 2.4.0 with ruby.

[Adam H. <sv...@ea...>]

Petr Vandrovec wrote:
>=20
> You must had select 'Athlon/K7' in configuration=2E
D'oh=2E

> On UP it works=2E But on SMP, in_interrupt() requires current and
> structure task_struct=2E And #include <linux/sched=2Eh>, which defines
> task_struct, needs string=2Eh=2E=2E=2E So this cannot work=2E=2E=2E
>=20
> There were two different patches sent to linux-kernel, how to fix it -
> - one was moving memcpy out-of-line, another was to not use
> current->processor, but ((unsigned long*)(current))[0x34/4]=2E
> One better than another ;-)
>=20
> Moving code out-of-line for SMP is probably better, as code generated
> by in_interrupt() on SMP is loooooong=2E

OK, interesting=2E

Now I've got a kernel that boots, but no input devices/console at
all=2E=2E=2E heh=2E Why is this? I have configured the kernel for ps/2 in 'I=
nput
device support' and chosen=20
'AT and PS/2 keyboards' and 'PS/2 mouse' in PS/2 port input devices=2E
What more do I need to do?

Not that I have several sets of keyboards/mice yet=2E I've got one set
(PS/2), I'll be testing with a USB keyboard shortly I believe=2E

Cheers,
--=20
Adam Huuva / Easter-eggs                 Sp=E9cialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  M=E9tro Gait=E9
Phone: +33 (0) 1 43 35 00 37    -   Fax: +33 (0) 1 41 35 00 76
mailto:sventon@easter-eggs=2Ecom  -   http://www=2Eeaster-eggs=2Ecom

Re: splitting ruby

[Christoph H. <hc...@ns...>]

On Wed, Jan 10, 2001 at 09:10:33AM -0800, James Simmons wrote:
> I agree except you will not see the rest of the input stuff go into
> 2.4.X. We will have to wait until 2.5.0. I have talked to Geert about this
> as well. I think the best attack plan is:
>
> 1) Dump all the input drivers into the console system.
> 2) Change all the fbdev drivers too.
> 3) Change the console system.
>
> I don't know if linus would be willing to dump all our work in at one
> time. If he would be willing to do so then I would dump it all in. This of
> course would require that we have partily working functionality on ALL
> platforms. I can test the stuff on PPC, sparcs and alpha as well but
> haven't yet. Plus I need to get into contact with the other platform
> developers for this.
 
I'd also favor the partially merge.
IMHO the following order is best:

1) move the busmouse code (excluding ps2, because it is more difficult)
   over to input in 2.5.<veryearly> and merge the serial mouse code.
2) move over the other input drivers to new-style input code.  This
   will include Martin's old version of keyboard.c for the input drivers.
3) merge the new console code.  If possible in smaller chunks, because
   Linus likes that.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: Compiling 2.4.0 with ruby.

[Petr V. <VAN...@vc...>]

On 11 Jan 01 at 16:02, Adam Huuva wrote:
> Petr Vandrovec wrote:
> > 
> > On 11 Jan 01 at 12:50, Adam Huuva wrote:
> > 
> > > >
> > > > Try the lastest CVS. It is fixed.
> > > OK. It is. Now I have this instead:
> > 
> > >                  from dummycon.c:11:
> > > /SDA3/usr/src/linux_patched/include/asm/hw_irq.h: In function
> > > `x86_do_profile':
> > > /SDA3/usr/src/linux_patched/include/asm/hw_irq.h:198: `current'
> > > undeclared (first use in this fun
> > > ction)
> > 
> > If you are reporting bug, try it first with stock kernel. You cannot
> > have Athlon/K7 with SMP. Either downgrade to UP, or to PIII.
> > 
> I have a(one) PIII. SMP was turned on by default. Apparently it does no
> harm, but I've turned it off now.
> Athlon/K7? I don't understand. Something I missed?

You must had select 'Athlon/K7' in configuration. In that case
memcpy uses

 if (len < 512 || in_interrupt())
   __memcpy(...);
 else
   __3dnow_memcpy(...);
   
On UP it works. But on SMP, in_interrupt() requires current and
structure task_struct. And #include <linux/sched.h>, which defines
task_struct, needs string.h... So this cannot work...

There were two different patches sent to linux-kernel, how to fix it -
- one was moving memcpy out-of-line, another was to not use
current->processor, but ((unsigned long*)(current))[0x34/4].
One better than another ;-)

Moving code out-of-line for SMP is probably better, as code generated
by in_interrupt() on SMP is loooooong.
                                            Petr
                                                                                    

Re: Compiling 2.4.0 with ruby.

[Adam H. <sv...@ea...>]

Petr Vandrovec wrote:
>=20
> On 11 Jan 01 at 12:50, Adam Huuva wrote:
>=20
> > >
> > > Try the lastest CVS=2E It is fixed=2E
> > OK=2E It is=2E Now I have this instead:
>=20
> >                  from dummycon=2Ec:11:
> > /SDA3/usr/src/linux_patched/include/asm/hw_irq=2Eh: In function
> > `x86_do_profile':
> > /SDA3/usr/src/linux_patched/include/asm/hw_irq=2Eh:198: `current'
> > undeclared (first use in this fun
> > ction)
>=20
> If you are reporting bug, try it first with stock kernel=2E You cannot
> have Athlon/K7 with SMP=2E Either downgrade to UP, or to PIII=2E
>=20
I have a(one) PIII=2E SMP was turned on by default=2E Apparently it does no
harm, but I've turned it off now=2E
Athlon/K7? I don't understand=2E Something I missed?

Now it compiles=2E Sorry=2E

Cheers,
--=20
Adam Huuva / Easter-eggs                 Sp=E9cialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  M=E9tro Gait=E9
Phone: +33 (0) 1 43 35 00 37    -   Fax: +33 (0) 1 41 35 00 76
mailto:sventon@easter-eggs=2Ecom  -   http://www=2Eeaster-eggs=2Ecom

Re: Compiling 2.4.0 with ruby.

[Petr V. <VAN...@vc...>]

On 11 Jan 01 at 12:50, Adam Huuva wrote:

> > 
> > Try the lastest CVS. It is fixed.
> OK. It is. Now I have this instead:

>                  from dummycon.c:11:
> /SDA3/usr/src/linux_patched/include/asm/hw_irq.h: In function
> `x86_do_profile':
> /SDA3/usr/src/linux_patched/include/asm/hw_irq.h:198: `current'
> undeclared (first use in this fun
> ction)

If you are reporting bug, try it first with stock kernel. You cannot
have Athlon/K7 with SMP. Either downgrade to UP, or to PIII.

                                        Petr Vandrovec
                                        van...@vc...
                                        

Re: Compiling 2.4.0 with ruby.

[Adam H. <sv...@ea...>]

James Simmons wrote:
> 
> Try the lastest CVS. It is fixed.
OK. It is. Now I have this instead:

gcc -D__KERNEL__ -I/SDA3/usr/src/linux_patched/include -Wall
-Wstrict-prototypes -O2 -fomit-frame
-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686    -c -o dummycon.o 
dummycon.c
In file included from
/SDA3/usr/src/linux_patched/include/linux/irq.h:57,
                 from
/SDA3/usr/src/linux_patched/include/asm/hardirq.h:6,
                 from
/SDA3/usr/src/linux_patched/include/linux/interrupt.h:45,
                 from
/SDA3/usr/src/linux_patched/include/linux/kbd_kern.h:4,
                 from
/SDA3/usr/src/linux_patched/include/linux/vt_kern.h:12,
                 from dummycon.c:11:
/SDA3/usr/src/linux_patched/include/asm/hw_irq.h: In function
`x86_do_profile':
/SDA3/usr/src/linux_patched/include/asm/hw_irq.h:198: `current'
undeclared (first use in this fun
ction)
/SDA3/usr/src/linux_patched/include/asm/hw_irq.h:198: (Each undeclared
identifier is reported onl
y once
/SDA3/usr/src/linux_patched/include/asm/hw_irq.h:198: for each function
it appears in.)
In file included from
/SDA3/usr/src/linux_patched/include/linux/kbd_kern.h:4,
                 from
/SDA3/usr/src/linux_patched/include/linux/vt_kern.h:12,
                 from dummycon.c:11:
/SDA3/usr/src/linux_patched/include/linux/interrupt.h: In function
`raise_softirq':
/SDA3/usr/src/linux_patched/include/linux/interrupt.h:89: `current'
undeclared (first use in this
 function)
/SDA3/usr/src/linux_patched/include/linux/interrupt.h: In function
`tasklet_schedule':
/SDA3/usr/src/linux_patched/include/linux/interrupt.h:160: `current'
undeclared (first use in thi
s function)
/SDA3/usr/src/linux_patched/include/linux/interrupt.h: In function
`tasklet_hi_schedule':
/SDA3/usr/src/linux_patched/include/linux/interrupt.h:174: `current'
undeclared (first use in thi
s function)
dummycon.c: At top level:
dummycon.c:64: unknown field `con_switch' specified in initializer
dummycon.c:65: duplicate initializer
dummycon.c:65: (near initialization for `dummy_con.con_blank')
dummycon.c:69: unknown field `con_scrolldelta' specified in initializer
dummycon.c:69: duplicate initializer
dummycon.c:69: (near initialization for `dummy_con.con_scroll')
make[4]: *** [dummycon.o] Error 1
make[4]: Leaving directory `/SDA3/usr/src/linux_patched/drivers/video'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory `/SDA3/usr/src/linux_patched/drivers/video'
make[2]: *** [_subdir_video] Error 2
make[2]: Leaving directory `/SDA3/usr/src/linux_patched/drivers'
make[1]: *** [_dir_drivers] Error 2
make[1]: Leaving directory `/SDA3/usr/src/linux_patched'
make: *** [stamp-build] Error 2


> You can send mne your .config file.
> 
OK. Thanks. It is attached.

> > Can I have a go on multiple consoles with cirrus logic (gd5480)
> > hardware?
> 
> Not yet. This requires rewriting the fbcon layer which I'm about to do.

So I can't run several vgacons on different graphics cards/chips yet
either?
Due to the bios restriction?

> > I have a hunch that multiple X sessions are a bit pre-mature
> > at the moment, but that's what I'm after in the long run.
> 
> It can be done with XFree86. You have to do a
> 
> start -vt 0
> start -vt 16
> 
> This tells it which vc to run on. For the ruby tree 16 VCs belong to one
> VT. Unfortunely I haven't got the fbcon layer going yet. Also for each
> fbdev driver we have to make them firmware independent as well. Since most
> video cards depend on the BIOS to intialize them. Unfortunely PC BIOS
> don't see multiple video cards so only the first one on the PCI bus gets
> intialized :-(

So not yet. But would the bios still initialize all heads on a multihead
card? No, I guess not, just the first. A job for linuxbios? :)

Cheers,
-- 
Adam Huuva / Easter-eggs                 Spécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37    -   Fax: +33 (0) 1 41 35 00 76
mailto:sv...@ea...  -   http://www.easter-eggs.com

Re: splitting ruby

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

> Well, I don't expect problems for PPC, as the adbhid.c driver is already 
> part of 2.4.0, (sigh, reminds me to merge PPC code between ruby and 2.4.0)

Does this include a fix for the USB keyboard double repeat problem. I
tried a USB keyboard on a G4 and if you typed to fast it double printed 
each character. The same driver on a ix86 doesn't show thsi problem. I
have never been able to figure out what it was.
 
> including the rest of the input code in 2.5.0 will just simplify the code 
> and clarify configuration (especially on HW supporting both ADB and PS2 
> keyboards) for us.

Yes. The keyboard multiplexer code is very nice :-) Makes life much
easier.

> My TODO list for the full input code merge on PPC is quite short:
>   - drop the emulate_raw() support for ADB keycodes, present in 2.4

How will X work? The way XFree86 works is it places the VT in raw mode and
grabs the keycodes. You have to patch X to use /dev/event instead which at
the rate of XFree86 developement could be years from now. I plan to add a
printk that states using RAW mode is outdated. I hope this annoyes the
hell out of the XFree86 guys so they do fix it.

>   - drop the emulation code for 2nd and 3rd mouse button (maybe not?)

Could the emulation be done in userland? If so they you coudl drop it.

>   - eventually write a handler kmmdev.c, that mixes keyboard and mouse 
> events onto a single device (similar to /dev/input/mice) running the event 
> protocol

Why?