linuxconsole-dev

Re: New input driver: Handykey's Twiddler as a joystick

[Arndt S. <ab...@sr...>]

On Tue, Jul 17, 2001 at 12:54:18PM -0700, James Simmons wrote:
> 
> Sorry about the delay but the code has been added to CVS.

Great! Thanks for your work, James!

There is one small thing left to be done: the symbols SERIO_TWIDKBD and
SERIO_TWIDJOY should be defined in include/linux/serio.h. The source
files util/inputattach.c and linux/drivers/input/twidjoy.c provide a
default for these values such as

    #ifndef SERIO_TWIDKBD
    #define SERIO_TWIDKBD 4710
    #endif

so they work as is, but this is only provisional. (I didn't submit
a patch for serio.h since I didn't want to guess what the next free
numbers would be by the time my code was integrated.)

And another question: Will the new driver be included into the next
Linux 2.4.x kernel version?

So long,
Arndt

-- 
Arndt Schönewald <ab...@sr...>, Software Developer

soft accel font drawing

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

Code is in CVS that has been tested on various pixel depths. It works
except the colors are wrong. It also doesn't work for non 8 bit width
fonts. I hope to have something ready for the end of the week.

Re: New input driver: Handykey's Twiddler as a joystick

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

Sorry about the delay but the code has been added to CVS.

Re: New Serial Driver arch ?

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

> I have rewritten a serial driver for a i386 
> z8530 card. I have found six drivers for the 8530.
> I plan rewriting/redesign a part from the serial io
> struct. I think i a good idea to split the driver in
> hw and arch layer for the 2.5 Kernel. 

This is good.

> Is in the linux-console project the rigth place for this ? 

Yes :-) Look in ruby/linux/drivers/serial. I will be working will
Russell King on this new serial core. Haven't gotten around to it 
yet. Basically we seperate the "driver" layer from the hardware layer.
This allows a serial tty to place on top or a serial terminal. If you
think about it it is kind of dumb to have a serial terminal for something
like a joystick plus their is a price to pay for going threw the serial
tty layer to obtain info.

> Sorry, when i mail for a old Problem. The mainpage from the
> Linux-Console is a little bit old, a have a few days search
> for this list.

We have no web maintainer :-( 

New Serial Driver arch ?

[Michael W. <mi...@dv...>]

Hallo,

I have rewritten a serial driver for a i386 
z8530 card. I have found six drivers for the 8530.
I plan rewriting/redesign a part from the serial io
struct. I think i a good idea to split the driver in
hw and arch layer for the 2.5 Kernel. 
Is in the linux-console project the rigth place for this ? 
Excuse me I begin with the Project, and read and analyse 
a big part of the code, step by step, and seach for all 
information. 
Sorry, when i mail for a old Problem. The mainpage from the
Linux-Console is a little bit old, a have a few days search
for this list.

michael

New serial code

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

To bring to peoples attention but I the current code seport.c has been
moved over to serport_old.c. serport_old.c is the code to register a
serial device to a serial line. serport.c is going to be a rewrite using a
new serial layer loosly based on Russel kings serial_core.c code. I
haven't had the chance yet to play with that code.

Re: X and the Input architecture

[Charles D. <cd...@mv...>]

On Wed, Jul 11, 2001 at 12:06:00PM -0700, lin...@li... wrote:
> I believe my driver is calling the input_report_abs with the correct
> values, but I am not 100% sure.  Is there a utility which will
> report the values the input architecture or X is receiving from a
> device?

Absolutely! Compile and install the evbug module to see the values the
input architecture reports (in your system logs), or xev to track X
events (assuming that you're capable of getting the pointer within the
xev window).

X and the Input architecture

[Ben V. H. <dai...@ya...>]

I am writing an input driver for UC-Logic Superpen USB
tablets and am running into some difficulties.  

When configuring the input device, I am setting absmax
to the appropriate values for this tablet (5500 and
4000, respectively) and the absmin values to 0. 
However, when I configure XFree86 to use
/dev/input/mice and insmod my new driver, the tablet
area does not seem to represent the full screen. 
There is a portion of the tablet which is "active",
and if I move outside of that area, the "active" area
moves, too.  The pressure readings also seem to be not
reaching X.

Mousedev is compiled and installed, with the screen
resolution set to 1024x768, which is my X resolution.

I have X configured to treat /dev/input/mice as a
IMPS/2 protocol device.  Is this correct?  I suspect
it is not but I cannot seem to find any reference to
what driver/device settings I should be using.

I believe my driver is calling the input_report_abs
with the correct values, but I am not 100% sure.  Is
there a utility which will report the values the input
architecture or X is receiving from a device?

Thanks very much for your time,
-Ben Von Handorf


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: Full m68k support.

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

> that would be quite nice as my current driver has several shortcommings
> which the input device solves. I hope the input device infrastructure
> gets quickly available in 2.4

I will gladly place the code in CVS :-)

Re: Full m68k support.

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

> isn't the input thing supposed to go into 2.5 ? 

Yes and no. You could convert it now and incorporate it into 2.4.X if
linus is willing to accept it.

Re: Full m68k support.

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

On Tue, Jul 10, 2001 at 10:22:09AM +0200, Richard Zidlicky wrote:
> On Mon, Jul 09, 2001 at 08:12:03AM -0700, James Simmons wrote:
> > 
> > > > > Do you know who know the atari and hp300 input hardware (keyboard,
> > > > > mice, joysticks) well so we can port the drivers to the input layer for
> > > > > ruby. I really like to wrap up support for this platform.
> > > > 
> > > > The m68k kernel hackers of course :-)
> > > 
> > > I can help about the atari input devices ... If you need help about
> > > anything, just ask me.
> > 
> > Great!! We pretty much toke code from the m68k tree and placed it into
> > CVS:-( It needs to be converted over. How well do you understand the
> > input api?
> 
> isn't the input thing supposed to go into 2.5 ? I am responsible for
> drivers/char/q40_keyb.c, will be probably pretty easy switch for me.
> There is just a simple irq handler that produces AT scancodes and
> acknowledges the irq. What makes the current driver so big is the 
> conversion AT->PC of scancodes which I hope will be done by the 
> input thing?

Yes, exactly so. Actually the input AT keyboard driver uses AT (as
opposed to PC/XT) scancodes natively, so no conversion needs to happen.

Now, if you could do the switch before 2.5 (in the ruby
tree), that'd help integrating the input stuff into 2.5 faster once
2.5 is out.

Its hard adding infrastructure and breaking working drivers even in a
development kernel, namely if the drivers are as important for use as
keyboard or console.

-- 
Vojtech Pavlik
SuSE Labs

Re: synaptics touchpad not working with 2.4.x (fwd)

[Arndt S. <ab...@sr...>]

On Tue, Jul 10, 2001 at 10:46:21AM +0200, Vojtech Pavlik wrote:
> > Does ruby allow to send data down to a psaux device? I will need this
> > functionality to improve the Linux support for the Twiddler2 (to allow
> > reprogramming of the chord-to-scancode mapping table which is kept
> > inside the device itself).
> 
> Not from userspace yet. But you can do it from a driver that'll plug
> between the i8042 driver and the atkbd/psmouse drivers.

That's fine for me! This driver could then have a /proc interface
to which user space code can write the desired mapping tables.

Thanks,
Arndt

Re: Full m68k support.

[Franz S. <Fra...@la...>]

At 10:22 10.07.2001, Richard Zidlicky wrote:
>On Mon, Jul 09, 2001 at 08:12:03AM -0700, James Simmons wrote:
> >
> > > > > Do you know who know the atari and hp300 input hardware (keyboard,
> > > > > mice, joysticks) well so we can port the drivers to the input 
> layer for
> > > > > ruby. I really like to wrap up support for this platform.
> > > >
> > > > The m68k kernel hackers of course :-)
> > >
> > > I can help about the atari input devices ... If you need help about
> > > anything, just ask me.
> >
> > Great!! We pretty much toke code from the m68k tree and placed it into
> > CVS:-( It needs to be converted over. How well do you understand the
> > input api?
>
>isn't the input thing supposed to go into 2.5 ? I am responsible for
>drivers/char/q40_keyb.c, will be probably pretty easy switch for me.
>There is just a simple irq handler that produces AT scancodes and
>acknowledges the irq. What makes the current driver so big is the
>conversion AT->PC of scancodes which I hope will be done by the
>input thing?

It's really easy to write an input driver, just register your device to the 
input layer on module insertion and then use input_report_key() if you have 
a keypress/keyrelease to report. And you report "Linux" keycodes (already 
in 2.4 include/linux/input.h) which are linear (!) and thus usually easy to 
create using a table. In the ruby CVS there is a file named 
utils/scancodes.h which should be (is?) the reference for all the tables in 
the input layer. To use it, just run for example:

         cd utils
         gcc -Dfrom=atari -Dto=code gencodes.c -o gencodes_atari_to_linux
         ./gencodes_atari_to_linux

You get a nice table you can just copy and paste into your source.

Franz.

Re: synaptics touchpad not working with 2.4.x (fwd)

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

On Tue, Jul 10, 2001 at 10:40:50AM +0200, Arndt Schoenewald wrote:
> Hi Vojtech,
> 
> while you are at it, talking about ruby's psaux driver:
> 
> On Mon, Jul 09, 2001 at 10:44:30PM +0200, Vojtech Pavlik wrote:
> > On Sun, Jul 08, 2001 at 08:50:37AM -0700, James Simmons wrote:
> > 
> > > Does the i8042 drivers we have support this device?
> > 
> > We don't have a specific driver for this. It should emulate a normal
> > PS/2 mouse, though.
> > 
> > The current 2.4 code chokes on the 0xaa character this device likes to
> > send and resets it quite often. The ruby code is protected against this
> > while still capable to detect mouse reconnects (the reason 0xaa handling
> > is in 2.4).
> > 
> > 2.4 can't be fixed, because of its psaux byte-stream oriented
> > architecture. 2.2 doesn't handle mouse reconnects. Ruby understand the
> > psmouse protocol and thus handles everything gracefully.
> 
> Does ruby allow to send data down to a psaux device? I will need this
> functionality to improve the Linux support for the Twiddler2 (to allow
> reprogramming of the chord-to-scancode mapping table which is kept
> inside the device itself).

Not from userspace yet. But you can do it from a driver that'll plug
between the i8042 driver and the atkbd/psmouse drivers.

-- 
Vojtech Pavlik
SuSE Labs

Re: synaptics touchpad not working with 2.4.x (fwd)

[Arndt S. <ab...@sr...>]

Hi Vojtech,

while you are at it, talking about ruby's psaux driver:

On Mon, Jul 09, 2001 at 10:44:30PM +0200, Vojtech Pavlik wrote:
> On Sun, Jul 08, 2001 at 08:50:37AM -0700, James Simmons wrote:
> 
> > Does the i8042 drivers we have support this device?
> 
> We don't have a specific driver for this. It should emulate a normal
> PS/2 mouse, though.
> 
> The current 2.4 code chokes on the 0xaa character this device likes to
> send and resets it quite often. The ruby code is protected against this
> while still capable to detect mouse reconnects (the reason 0xaa handling
> is in 2.4).
> 
> 2.4 can't be fixed, because of its psaux byte-stream oriented
> architecture. 2.2 doesn't handle mouse reconnects. Ruby understand the
> psmouse protocol and thus handles everything gracefully.

Does ruby allow to send data down to a psaux device? I will need this
functionality to improve the Linux support for the Twiddler2 (to allow
reprogramming of the chord-to-scancode mapping table which is kept
inside the device itself).

Thank you,
Arndt

Re: Full m68k support.

[Richard Z. <Ric...@st...>]

On Mon, Jul 09, 2001 at 08:12:03AM -0700, James Simmons wrote:
> 
> > > > Do you know who know the atari and hp300 input hardware (keyboard,
> > > > mice, joysticks) well so we can port the drivers to the input layer for
> > > > ruby. I really like to wrap up support for this platform.
> > > 
> > > The m68k kernel hackers of course :-)
> > 
> > I can help about the atari input devices ... If you need help about
> > anything, just ask me.
> 
> Great!! We pretty much toke code from the m68k tree and placed it into
> CVS:-( It needs to be converted over. How well do you understand the
> input api?

isn't the input thing supposed to go into 2.5 ? I am responsible for
drivers/char/q40_keyb.c, will be probably pretty easy switch for me.
There is just a simple irq handler that produces AT scancodes and
acknowledges the irq. What makes the current driver so big is the 
conversion AT->PC of scancodes which I hope will be done by the 
input thing?

Bye
Richard

Re: [ANNOUNCE] Synced with 2.4.6

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

> I just tagged the tree with tag "two-four-six". I hope no file commited
> since your announce broke the compatibility.

Nope. Their where some changes for the serial core stuff. In fact their is
a bug in serial_sa1100 I have to fix but you don't need to worry about
that.

Re: [ANNOUNCE] Synced with 2.4.6

[Johann D. <jo...@Do...>]

On Sun, 8 Jul 2001, James Simmons wrote:

> 
> I just finished the finally syncing with Linus 2.4.6 tree and Russell
> kings 2.4.6-rmk1 tree. I tested both and they work :-) The tree also
> should work with the latest PPC tree thanks to Frank Sirl. 
> 

I just tagged the tree with tag "two-four-six". I hope no file commited
since your announce broke the compatibility.

-- 
Johann Deneux

Re: synaptics touchpad not working with 2.4.x (fwd)

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

On Sun, Jul 08, 2001 at 08:50:37AM -0700, James Simmons wrote:

> Does the i8042 drivers we have support this device?

We don't have a specific driver for this. It should emulate a normal
PS/2 mouse, though.

The current 2.4 code chokes on the 0xaa character this device likes to
send and resets it quite often. The ruby code is protected against this
while still capable to detect mouse reconnects (the reason 0xaa handling
is in 2.4).

2.4 can't be fixed, because of its psaux byte-stream oriented
architecture. 2.2 doesn't handle mouse reconnects. Ruby understand the
psmouse protocol and thus handles everything gracefully.

> ---------- Forwarded message ----------
> Date: Sun, 8 Jul 2001 22:49:30 +1000
> From: CaT <ca...@zi...>
> To: lin...@vg...
> Subject: synaptics touchpad not working with 2.4.x
> 
> I;ve had this with 2.4.0 but have just tried with 2.4.6ac2 and still
> have it.
> 
> Under 2.2.x the touchpad works like a dream. Under 2.4.x it stutters,
> freezes and so on. Did something about /dec/psaux change between 2.2.x
> and 2.4.x? Will I need to recompile glibc and/or gpm?
> 
> if I cat /dev/psaux I get data flowing through but gpm stays frozen. :/
> 
> Hope someone can help as, now that ext3 is being well and truly ported 
> to 2.4.x, this is the last stumbling block for me having 2.4.x on
> my laptop.
> 
> gpm options: /usr/sbin/gpm -m /dev/psaux -t synps2 -Rmsc -2
> glibc: 2.1.3 compiled for 2.2.x
> 
> -- 
> CaT (ca...@zi...)		*** Jenna has joined the channel.
> 				<cat> speaking of mental giants..
> 				<Jenna> me, a giant, bullshit
> 				<Jenna> And i'm not mental
> 					- An IRC session, 20/12/2000
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

-- 
Vojtech Pavlik
SuSE Labs

Q: Can a driver other than keybdev be used for a HID keyboard?

[Arndt S. <ab...@sr...>]

Hi input system architects,

I wonder how exactly connected devices are connected with the available
event handlers like keybdev, mousedev, and joydev, and whether it is
influence this decision.

From the Linux kernel sources I can see that new device instances are
registered by their driver, e.g. from hid.c or stinger.c, with the input
system by means of input_register_device(). This function then calls
the connect() function of any available event handlers such as keybdev,
mousedev, and joydev which decide whether they want to receive and handle
the input device's events. Every event received from an input device is
posted to all event handlers which are registered for this input device.

So far so good. But what if I have one USB HID device for which I want
a different handler than keybdev, mousedev, and joydev to be used?
For example, I have a "normal" USB keyboard that is handled by keybdev,
which is fine, but then I have an additional USB HID keyboard, a small
number pad (an add-on keyboard meant for faster data entry on notebooks),
for which I would like to use a handler module of my own to make it
generate different keystrokes (i.e. use a different translation table)
or even gamepad events.

Is this possible? How is the order determined in which the connect()
function of the handlers are called? Can a handler "eat up" an event so
that it is not presented to handlers which are later on in the chain?

Thank you,
Arndt

Re: Full m68k support.

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

> > > Do you know who know the atari and hp300 input hardware (keyboard,
> > > mice, joysticks) well so we can port the drivers to the input layer for
> > > ruby. I really like to wrap up support for this platform.
> > 
> > The m68k kernel hackers of course :-)
> 
> I can help about the atari input devices ... If you need help about
> anything, just ask me.

Great!! We pretty much toke code from the m68k tree and placed it into
CVS :-( It needs to be converted over. How well do you understand the
input api?

> just to know ... What's "ruby" ? :)

Ruby is the name of the kernel tree for the linux console project. The
linux console project is about rewriting the console system in the
following ways:

1) A new api for framebuffer drivers. Makes driver writing much easier 
   and it seperates the console layer from the framebuffer layer allowing
   the fbdev layer to run without a console system.

2) Use the input api has the backbone for the console system on the input
   side. It has the advantage of a simpler api, universal keymap, and
   access to a keyboard without a console system. 

3) Rewriting the serial layer in a similar fashion to parport. 

Other things come out of it like multihead.

New input driver: Handykey's Twiddler as a joystick

[Arndt S. <ab...@sr...>]

Hi folks,

here is another input device driver for Linux 2.4 and ruby; it allows to
use Handykey's Twiddler (the original, RS232 version) as a joystick.

The Twiddler (http://www.handykey.com) is probably the most famous and
popular input device for wearable computers, many of which run Linux.
It is actually meant as a chording keyboard; you press multiple keys
simultaneously (a chord), and a keystroke is generated as soon as the
keys are released. To make this work, the Twiddler continuously sends
data packets describing the state of the keys up the serial line, and a
daemon process picks them up, analyzes them, consults a chord-to-keystroke
mapping table, and inserts the resulting keystrokes into the system. The
Linux version of this daemon currently does this using the TIOCSTI ioctl,
if a text console is active, or by means of the external program a2x,
if the current console is the one where the X server runs. This approach
has a couple of disadvantages; it would be much nicer if the Twiddler
was handled by a kernel module that could directly inject the keystrokes
into the system just like the keystrokes from other keyboards, perhaps
totally obviating the need for the daemon process, but at least obviating
the need to maintain different sets of chord-to-keystroke mappings for
X and console applications.

With this goal in mind, I went through the Linux 2.4. kernel sources to
look for ways how it could be done. This was when I first discovered
Vojtech's great new input framework that does not only make things like
this possible, but even easy. And after some more searching and browsing,
I came across The Linux Console Project and its Sourceforge pages.

So here is my first shot. The attached Twiddler driver, "twidjoy", is
quite simple, and it does a lot less than the chord-to-keystroke mapping
daemon mentioned above, but what it does is very useful in its own
right: It turns the Twiddler into a joystick with 2 analog axes (did I
mention that the Twiddler also has a built-in tilt sensor?!) and whopping
18 buttons! (And yes, all of them can be used with Unreal Tournament!)

The driver comes together with the appropriate additions to inputattach
which allow to select the "twidjoy" driver and check that the Twiddler is
present. I plan on writing another driver module, code-named "twidkbd",
that will then implement the Twiddler's standard chording behaviour
(i.e. generating keystrokes from button chords and mouse events from the
tilt sensor), so support for this upcoming driver is already present in
the submitted inputattach code, too. (My priority for the implementation
of "twidkbd" is a bit lower, though, because I will first try to improve
the Linux support for the newly available Twiddler2, but if someone
needs this and/or wants to help writing it, let me know.)

To develop the code, I checked out ruby from the CVS on Friday, modified
the file "utils/inputattach.c" and created "twidjoy.c" from the template
"linux/drivers/input/stinger.c". Since the relevant source files of the
input system in stock 2.4.5, 2.4.6, and ruby are mostly the same, I assume
that the driver should work with all of these Linux flavors. However, I
have myself only tried it with kernel 2.4.5 (stock, i.e. without ruby).
If the module passes your introspection and tests, I would very much like
to see it included into the 2.4 kernel branch.

Have fun with it!
Arndt

PS: This driver does NOT support the Twiddler2, which directly connects
to the PS/2 keyboard and mouse ports. The Twiddler2 does not need any
special drivers, so it works with Linux out of the box -- albeit not as
a 18 buttons joystick ;-)

-- 
Arndt Schoenewald <ab...@sr...>
Ostenhellweg 31, 44135 Dortmund, Germany
Tel: +49 231 556075

Re: Full m68k support.

[<fg...@en...>]

On Mon, 9 Jul 2001, Geert Uytterhoeven wrote:

> On Sun, 8 Jul 2001, James Simmons wrote:
> > Do you know who know the atari and hp300 input hardware (keyboard,
> > mice, joysticks) well so we can port the drivers to the input layer for
> > ruby. I really like to wrap up support for this platform.
>=20
> The m68k kernel hackers of course :-)

I can help about the atari input devices ... If you need help about
anything, just ask me.

just to know ... What's "ruby" ? :)


- Fran=E7ois Galea -

Re: Full m68k support.

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

On Sun, 8 Jul 2001, James Simmons wrote:
> Do you know who know the atari and hp300 input hardware (keyboard,
> mice, joysticks) well so we can port the drivers to the input layer for
> ruby. I really like to wrap up support for this platform.

The m68k kernel hackers of course :-)

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

Soft accel engine font drawing.

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

I finally sat down and pounded out some code. Basically I just started
from scratch. It works for only 8 bpp modes. Sorry. It also is not
optimizated at all. So Frank if you want to give it a try with the OF
framebuffer go for it. It should complie and work. I tested the font
drawing code on my 3dfx card, of course with no acceleration.