linuxconsole-dev

Re: evdev types

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

On Mon, Apr 15, 2002 at 08:41:33PM +1000, Brad Hards wrote:
> On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > Yes, if this is cleaner. I have much bigger worries about the size of
> > 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> > support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
> Oh. Ugly.

Yeah. setbit() et al work on longs, and longs are OK in an API which
isn't on a mixed 32/64-bit arch. But since the 32/64 bit stuff happens,
it gets pretty ugly.

> I thought that those definitions were purely internal - I hadn't got that far 
> into the detail of the API.

Unfortunately they are not - they can't be - apps need to know what
valuators, keys, whatever the device has.

> I'll continue along with the documentation/tutorial, and raise questions / 
> patches as appropriate.
> 
> BTW: The documentation is for USB HID, to try to answer questions for 
> developers of products and userspace apps.
> It covers hiddev, evdev, joystick (including force feedback), mouse and 
> keyboard.

God bless you for that. It is really needed. And I never can get me to
write docs. :(

> I am doing hiddev and evdev in detail, since I think these are basically 
> undocumented. I've just done a couple of ioctl examples for each so far.
> I am doing joystick by direct reference to the kernel docs - I may copy the 
> kernel files into the documentation (and docbook them) at a later stage and 
> add some examples, but the initial work work will be on evdev and hiddev, and 
> there is plenty there.

That's exactly what's needed - actually joydev (and its api) is
obsoleted by evdev.

> What is missing is keyboard and mouse. I'd be willing to leave out keyboard 
> (because the stdin/scanf/getc semantic is probably enough.

There isn't any keyboard API other than evdev and the console.

> What I don't have 
> is mouse coverage. Does anyone have a good pointer to programming with the 
> PS2 variations? I was thinking about just pointing to libgpm, but that 
> doesn't really explain what comes out of /dev/input/mouse[0..30] when you 
> read. 

 /dev/input/mouse[0..30] simulates (quite exactly, both directions) the
protocol of Microsoft IntelliMouse Explorer. But no new applications
should use it, evdev is more powerful and easier to write for.

I hope both mousedev and joydev will not be needed by 2.6 (2.8) or so.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

[Brad H. <bh...@bi...>]

On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> Yes, if this is cleaner. I have much bigger worries about the size of
> 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
Oh. Ugly.
I thought that those definitions were purely internal - I hadn't got that far 
into the detail of the API.

I'll continue along with the documentation/tutorial, and raise questions / 
patches as appropriate.

BTW: The documentation is for USB HID, to try to answer questions for 
developers of products and userspace apps.
It covers hiddev, evdev, joystick (including force feedback), mouse and 
keyboard.
I am doing hiddev and evdev in detail, since I think these are basically 
undocumented. I've just done a couple of ioctl examples for each so far.
I am doing joystick by direct reference to the kernel docs - I may copy the 
kernel files into the documentation (and docbook them) at a later stage and 
add some examples, but the initial work work will be on evdev and hiddev, and 
there is plenty there.

What is missing is keyboard and mouse. I'd be willing to leave out keyboard 
(because the stdin/scanf/getc semantic is probably enough. What I don't have 
is mouse coverage. Does anyone have a good pointer to programming with the 
PS2 variations? I was thinking about just pointing to libgpm, but that 
doesn't really explain what comes out of /dev/input/mouse[0..30] when you 
read. 

Brad

Re: evdev types

[Brad H. <bh...@bi...>]

On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
<snip>
> Feel free to submit a patch. :) I'll most likely accept it.
OK. I'll attack this problem in small chunks.

Patch against evtest.c and patch against 2.4.19-pre6 attached, just attacking 
the EVIOCGID ioctl at this stage. Note that most of the kernel changes are in 
driver/usb.

How does this look?

Brad

Re: ruby Trouble with new hardware

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

>> Hi
>> Now I have KT266 chipset motherboard.
>> I couldn't start my TNT2 (AGP) X sever.
>> X will start, when after 1-4 seconds freezy.
>> Any other X (PCI) run as nothing happen although X(AGP) freezy.
>> System will not reboot.
>> Tested open and closed source nvidia drivers, lots of BIOS setings.
>>
>> Trouble only with linux-ruby.
>> I don't use CVS ruby . Couldn't say which tree.
>> 99.99% is from ruby-2.5.2
>> 2.4.18 kernel patched.
>>
>> No problems with older 440ZX chipset.
>>
>> Can You get me tiny guidance of bug hunting?
>
>Can you post the output of dmesg ?

Possible bugy TNT2 AGP removed.
I try MTTR on/off agpart on/off  - same results.
Forgotten try out pci=biosirq.

Linux version 2.4.18-backstreet-ruby (root@localhost) (gcc version 2.95.3
20010315 (release)) #34 SMP Thu Apr 11 20:44:49 GMT 2002
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
 BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Found and enabled local APIC!
Kernel command line: BOOT_IMAGE=linux ro root=303 BOOT_FILE=/vmlinuz
dumbcon=2
Initializing CPU#0
Detected 1401.735 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 2798.38 BogoMIPS
Memory: 255352k/262080k available (1206k kernel code, 6340k reserved, 385k
data, 220k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rg...@at...)
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0383fbff c1cbfbff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0383fbff c1cbfbff 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU:             Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU0: AMD Athlon(tm) XP 1600+ stepping 02
per-CPU timeslice cutoff: 731.34 usecs.
SMP motherboard not detected.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1401.6407 MHz.
..... host bus clock speed is 266.9792 MHz.
cpu: 0, clocks: 2669792, slice: 1334896
CPU0<T0:2669792,T1:1334896,D:0,S:1334896,C:2669792>
Waiting on wait_init_idle (map = 0x0)
All processors have done init_idle
PCI: PCI BIOS revision 2.10 entry at 0xfb430, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router default [1106/3099] at 00:00.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Console: mono dumb device 80x25
Console: mono dumb device 80x25
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: 128 slots per queue, batch=32
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using
pci=biosirq.
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
    ide0: BM-DMA at 0xd400-0xd407, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:DMA, hdd:pio
hda: FUJITSU MPG3409AT E, ATA DISK drive
hdc: _NEC DV-5800A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 80063424 sectors (40992 MB) w/2048KiB Cache, CHS=4983/255/63,
UDMA(100)
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 hda3 hda4
FDC 0 is a post-1991 82077
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected Via Apollo Pro KT266 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
es1371: version v0.30 time 20:45:42 Apr 11 2002
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x06
es1371: found es1371 rev 6 at io 0xd000 irq 7 joystick 0x0
ac97_codec: AC97  codec, id: 0x5452:0x4123 (TriTech TR A5)
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
uhci.c: USB UHCI at I/O 0xd800, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: USB UHCI at I/O 0xdc00, IRQ 11
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
hid-core.c: v1.31:USB HID core driver
mice: PS/2 mouse device common for all mice
input.c: calling hotplug without valid filesystem
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
input.c: calling hotplug without valid filesystem
input: AT Set 2 keyboard on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 220k freed
Adding Swap: 409648k swap-space (priority -1)
NVRM: loading NVIDIA NVdriver Kernel Module  1.0.2313  Tue Nov 27 12:01:24
PST 2001
spurious 8259A interrupt: IRQ7.

Re: ruby : A bit simpler keyboard adding for multiple locale X servers

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

>> Here is dumb console driver created by me for X.
>
>Hm. I see dummycon has come back to tease me.

Now these is kids tested and mother aproved.
I couldn't find other way start "unlimited" count of X.
Of course current only two X is started - no more monitors.
Large tuxracing campaign. :))

>> Dumb console create VT and then do nothig.
>> All work do linuxconsole vt-manager.
>> You can configure dumb with kernel command line "dumbcon=x",
>> where x is number of dumb consoles.
>> Every console is binded with /dev/tty's depended from
>> MAX _NR_USER_CONSOLES.
>
>Hm. Go add about the number of VTs.
>

My coredistro.sourceforge.net has only /dev/tty1-tty10.
Therefore I use MAX_NR_USER_CONSOLES==4.

>> Sample:
>> file vt_kern.h
>> #define MAX_NR_USER_CONSOLES 4
>
>MAX_NR_USER_CONSOLES is how many VCs per VT device. This is always 16.
>MAX_NR_CONSOLES represents how many total VCs you can have. Dividing the
>two you see wwe can have at most 4 VTs.

So I have 4 VCs per VT and 4 /dev/tty's per VT.
Any have enough /dev/tty files can use different
MAX_NR_USER_CONSOLES definition.


>> This are tested by me with xdm, triple graphic login succesfully run.
>> Edit /etc/X11/xdm/Xservers .
>> Seems kdm, gdm don't like multiple X or wrong configuration on my end.
>> X patch is necessary.
>
>Can you post the patch :-)
>
I couldn't explain this patch.
Patch was posted by Mr. svetljo to linuxconsole mailing list.
May be he has different results. This work for me.
Seems X try to find all video cards and stop their PCI access.
We remove this feature ;-).
IMHO Complete patch must create different X0.lock file,
then X1 check X0.lock and do not disable X0 PCI access and vice versa.

Know bugs:
hardware GLX may be unstable , unsure about this , any other app can
hung up system.
halt sometimes will not stop one X - system hung up.
RedHat xfs will grab 30-60% CPU ~10min definitely slow down system - I stop
it.
RedHat fam will grab 99% CPU ~5min or more - I stop xinetd.

--- xc\programs\Xserver\hw\xfree86\common\xf86pciBus.c.original   Fri Nov
30 14:11:55 2001
+++ xc\programs\Xserver\hw\xfree86\common\xf86pciBus.c  Mon Apr 15 10:10:41
2002
@@ -584,9 +584,11 @@
 #ifdef DEBUG
     ErrorF("pciIoAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
                ((pciArg*)arg)->ctrl);
+#endif
 }

 #undef SETBITS
@@ -608,9 +610,11 @@
 #ifdef DEBUG
     ErrorF("pciIo_MemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
                ((pciArg*)arg)->ctrl);
+#endif
 }

 #undef SETBITS
@@ -632,9 +636,11 @@
 #ifdef DEBUG
     ErrorF("pciMemAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
 #endif
+#if 0
     ((pciArg*)arg)->ctrl &= ~SETBITS;
     ((pciArg*)arg)->func(((pciArg*)arg)->tag, PCI_CMD_STAT_REG,
                ((pciArg*)arg)->ctrl);
+#endif
 }
 #undef SETBITS


>> Q: Why linuxconsole vt-manager is better as separate keyboard driver for
X.
>> A: Linuxconsole project already have tons of keyboard drivers. All You
can
>> add to X
>>      via /dev/tty.
>
> Well XFree86 is currently based on using the VT. This will go away in the
> future. I already have spoken to Jim Getty about this and he already is
> working on making XFree86 independent of VT switching and to use the
input
> api!!! Yeah!!!!


Very far future ?

Re: evdev types

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

On Mon, Apr 15, 2002 at 04:23:09PM +1000, Brad Hards wrote:

> Gday all,
> 
> In my continuing journey of documentation, I got to EVIOCGID, which returns 
> short[4]. Is there any reason why that couldn't be a 
> struct evdev_ident (or input_ident)
> {
> 	uint16_t bustype;
> 	uint16_t vendor_id;
> 	uint16_t product_id;
> 	uint16_t version;
> };

Yes, if this is cleaner. I have much bigger worries about the size of
'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
support mixed 32/64-bit binaries (SPARC, PPC, x86-64).

> Similarly, 
> struct ff_replay probably should be
> {
>         uint16_t length;           /* Duration of an effect */
>         uint16_t delay;            /* Time to wait before to start playing an 
> effect */
> };
> 
> because __u16 is inherently non-portable (refer Linux Device Drivers book, 
> Chapter 10), not to mention being even uglier than the [type]_t notation. No 
> mean feat :)
> 
> And same principle for the other ff_ structures.
> 
> The followon from this would be for the internal struct input_dev to contain a 
> struct evdev_ident (or input_ident) instead of the 
>         unsigned short idbus;
>         unsigned short idvendor;
>         unsigned short idproduct;
>         unsigned short idversion;
> 
> Any thoughts?

Feel free to submit a patch. :) I'll most likely accept it.

-- 
Vojtech Pavlik
SuSE Labs

evdev types

[Brad H. <bh...@bi...>]

Gday all,

In my continuing journey of documentation, I got to EVIOCGID, which returns 
short[4]. Is there any reason why that couldn't be a 
struct evdev_ident (or input_ident)
{
	uint16_t bustype;
	uint16_t vendor_id;
	uint16_t product_id;
	uint16_t version;
};

Similarly, 
struct ff_replay probably should be
{
        uint16_t length;           /* Duration of an effect */
        uint16_t delay;            /* Time to wait before to start playing an 
effect */
};

because __u16 is inherently non-portable (refer Linux Device Drivers book, 
Chapter 10), not to mention being even uglier than the [type]_t notation. No 
mean feat :)

And same principle for the other ff_ structures.

The followon from this would be for the internal struct input_dev to contain a 
struct evdev_ident (or input_ident) instead of the 
        unsigned short idbus;
        unsigned short idvendor;
        unsigned short idproduct;
        unsigned short idversion;

Any thoughts?

Brad

Re: Console Support for event devices.

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

On Sat, Apr 13, 2002 at 01:23:16PM -0400, Thomas H Hendrick wrote:
> > On Fri, Apr 12, 2002 at 03:18:40PM -0400, Thomas H Hendrick wrote:
> > > I was thinking that it would be nice if we could include support for
> user-space
> > > programs to request that events (/dev/input/eventX) only be sent to a file
> > > descriptor when they are the foreground terminal.  I am going to play with
> this
> > > idea on my branch so it doesn't pollute the current devel code.  If we like
> it,
> > > we can merge when the time comes.
> > >
> > > The idea is that the input_event struct provides all the wonderful
> information
> > > that programs will need.  However, between input and the user is some
> > > boiling/refining that removes some of the unnecessary information that
> probably
> > > 90-95% of all user-space programs don't care about.  For them, stdin/stdio
> takes
> > > care of all of their needs.
> > >
> > > For that other 5-10%, the event device provides all the information you
> would
> > > need to do mouse, keyboard, etc.  However you will get ALL events destined
> for
> > > ALL consoles/terminals/etc, regardless of whether it was intended for you or
> vc
> > > 6 or the X-server or some x-term ... etc.
> >
> > xterm? Uh-huh, how? xterms get mouse/keyboard data via the X protocol.
> 
> Sorry.  Meant something else.
> 
> > Actually a much more interesting project would be to write a console as
> > an userspace program connecting to /dev/pty's and using input and
> > framebuffers to implement all that's expected from a console. Including
> > nifty stuff like complete Unicode support, etc.
> 
> > > I know by the end of 2.5.X I'm going to be nicknamed "The Ioctl Avenger" or
> > > something, but my current idea is to leave the devices are they are
> currently,
> > > and just add support for an ioctl, EVIOCCONSOLEONLY, which will signal to
> the
> > > event driver to only deliver events to a particular struct file when it is
> > > associated with the foreground console.  The rest is just adding the check
> to
> > > see if the pid of the file-owner is the same as the pid of the foreground vc
> > > owner before delivering the event.
> >
> > I don't think this is a good idea. The app can filter that itself with
> > no problems, while it adds a lot of cruft into the kernel if implemented
> > there.
> 
> Well, the problem is that if an event comes into a program, it will have no idea
> if that event was meant for it, or another program on a different console. 

The program can know which console is active and which console it is
running on, thus can know whether the event is meant for it or not.

> The
> kernel takes care of stdin, but the event devices don't have that capability.

Because they're much more low-level, yes. That's intended.

> So, if programs wanted to use /dev/input/eventX for input instead of stdin,

That's of course impossible because of the completely different data
format, for example.

> they would get ALL of the events that the input device generates
> regardless of who has the device focus. 

Input is vt/console agnostic - it doesn't know and doesn't want to know
anything about virtual terminals or consoles, they're a layer above
input. It must work just fine even without any console code (and it
does).

> Like I said, I figured that
> I'd play with it on a branch.

And I won't accept it into the mainstream, unless you bring some
stronger arguments why it is really needed. If there are any programs
that would benefit from it.

> > > There is one downside, however, that
> > > programs using the event device which may have more than one console open
> will
> > > not know which console the event occurred on, unless the input_event struct
> is
> > > changed to include a vc number - or- they open each event device multiple
> times,
> > > and register a different vc for each one.  There is a possible security
> risk,
> > > however, if I just let an program register to listen for events on any vt.
> Not
> > > that it isn't a risk already, to some degree.  (A potential malcontent could
> ssh
> > > to a machine they have an account on, and use evtest to listen to the
> keyboard.
> > > They just need to look for KEY_EVENT "r" "o" "o" "t" "KEY_ENTER" "p" "a" "s"
> "s"
> > > "w" "o" "r" "d" KEY_ENTER.  Like I said, I'll play with it.
> >
> > Actually, no. They should be root-readable only anyway, and root isn't
> > interested in his own password.
> 
> Noted.  Wonder why mine was set to ugo+rw...

Tracking the mouse or whatever is similarly dangerous. Note that even if
you added VT-switching support into evdev (or deeper into input), it
won't help, because the application still can not enable it and get all
events.

Anyway, what you might be aiming at is adding 'event' protocol support
to the console, in addition to the raw and medium raw protocols. It
might be interesting, yes. I think (extended) medium raw, as available
now in ruby is quite enough anyway.

> > > The alternative to the Ioctl idea was to add separate /dev/input devices
> that
> > > would be associated with particular terminals, but each input device would
> need
> > > a file associated with each terminal, and ... well, that's just ugly, IMHO.
> > >
> > > Like I said, I'm gonna branch this so it doesn't pollute.
> > >
> > > On the flip side of things, I'm hammering away on the user-space program to
> swap
> > > in keymaps.  I have implemented the full keymap ioctl's to transfer the
> keymap
> > > data all-at-once.  I will remove the older ioctl's, and test the newer ones
> once
> > > I get the user-space program finished.
> >
> > Keep in mind that the keymaps will have different sizes and different
> > cell sizes as well. They may be 256 bytes or 512 shorts or anything else
> > on different keyboards.
> 
> Already taken into account.  The code that you had already placed there took
> care of the data-sizing, so I copied the relevant bits to adjust the size as
> appropriate.  Like I said, I'll test it once I get the user-space program
> together, which I've been busy the past couple of days and I haven't been coding
> much.
> 
> BTW, is there a "release date" for 2.6.0 rumored, talked about, scheduled,
> anything?

No, of course not. We've just started the 2.5 series.

-- 
Vojtech Pavlik
SuSE Labs

Re: Console Support for event devices.

[Thomas H H. <wy...@at...>]

> On Fri, Apr 12, 2002 at 03:18:40PM -0400, Thomas H Hendrick wrote:
> > I was thinking that it would be nice if we could include support for
user-space
> > programs to request that events (/dev/input/eventX) only be sent to a file
> > descriptor when they are the foreground terminal.  I am going to play with
this
> > idea on my branch so it doesn't pollute the current devel code.  If we like
it,
> > we can merge when the time comes.
> >
> > The idea is that the input_event struct provides all the wonderful
information
> > that programs will need.  However, between input and the user is some
> > boiling/refining that removes some of the unnecessary information that
probably
> > 90-95% of all user-space programs don't care about.  For them, stdin/stdio
takes
> > care of all of their needs.
> >
> > For that other 5-10%, the event device provides all the information you
would
> > need to do mouse, keyboard, etc.  However you will get ALL events destined
for
> > ALL consoles/terminals/etc, regardless of whether it was intended for you or
vc
> > 6 or the X-server or some x-term ... etc.
>
> xterm? Uh-huh, how? xterms get mouse/keyboard data via the X protocol.

Sorry.  Meant something else.

> Actually a much more interesting project would be to write a console as
> an userspace program connecting to /dev/pty's and using input and
> framebuffers to implement all that's expected from a console. Including
> nifty stuff like complete Unicode support, etc.

> > I know by the end of 2.5.X I'm going to be nicknamed "The Ioctl Avenger" or
> > something, but my current idea is to leave the devices are they are
currently,
> > and just add support for an ioctl, EVIOCCONSOLEONLY, which will signal to
the
> > event driver to only deliver events to a particular struct file when it is
> > associated with the foreground console.  The rest is just adding the check
to
> > see if the pid of the file-owner is the same as the pid of the foreground vc
> > owner before delivering the event.
>
> I don't think this is a good idea. The app can filter that itself with
> no problems, while it adds a lot of cruft into the kernel if implemented
> there.

Well, the problem is that if an event comes into a program, it will have no idea
if that event was meant for it, or another program on a different console.  The
kernel takes care of stdin, but the event devices don't have that capability.
So, if programs wanted to use /dev/input/eventX for input instead of stdin, they
would get ALL of the events that the input device generates regardless of who
has the device focus.  Like I said, I figured that I'd play with it on a branch.

> > There is one downside, however, that
> > programs using the event device which may have more than one console open
will
> > not know which console the event occurred on, unless the input_event struct
is
> > changed to include a vc number - or- they open each event device multiple
times,
> > and register a different vc for each one.  There is a possible security
risk,
> > however, if I just let an program register to listen for events on any vt.
Not
> > that it isn't a risk already, to some degree.  (A potential malcontent could
ssh
> > to a machine they have an account on, and use evtest to listen to the
keyboard.
> > They just need to look for KEY_EVENT "r" "o" "o" "t" "KEY_ENTER" "p" "a" "s"
"s"
> > "w" "o" "r" "d" KEY_ENTER.  Like I said, I'll play with it.
>
> Actually, no. They should be root-readable only anyway, and root isn't
> interested in his own password.

Noted.  Wonder why mine was set to ugo+rw...

> > The alternative to the Ioctl idea was to add separate /dev/input devices
that
> > would be associated with particular terminals, but each input device would
need
> > a file associated with each terminal, and ... well, that's just ugly, IMHO.
> >
> > Like I said, I'm gonna branch this so it doesn't pollute.
> >
> > On the flip side of things, I'm hammering away on the user-space program to
swap
> > in keymaps.  I have implemented the full keymap ioctl's to transfer the
keymap
> > data all-at-once.  I will remove the older ioctl's, and test the newer ones
once
> > I get the user-space program finished.
>
> Keep in mind that the keymaps will have different sizes and different
> cell sizes as well. They may be 256 bytes or 512 shorts or anything else
> on different keyboards.

Already taken into account.  The code that you had already placed there took
care of the data-sizing, so I copied the relevant bits to adjust the size as
appropriate.  Like I said, I'll test it once I get the user-space program
together, which I've been busy the past couple of days and I haven't been coding
much.

BTW, is there a "release date" for 2.6.0 rumored, talked about, scheduled,
anything?

--Tom.

Re: Paper

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

On Fri, Apr 12, 2002 at 02:27:10PM -0700, James Simmons wrote:
> 
> Hi!
> 
>    I just placed in CVS a html version of a paper I plan to present at a
> talk in Ottowa soon. Have a look at:
> 
> http://linuxconsole.sf.net/paper
> 
> Yes lots is missing, I just started. I'm leaving the input section to you
> Vojtech to fill in.

Ok. I'll try to find the time to do it soon.

-- 
Vojtech Pavlik
SuSE Labs

Re: Console Support for event devices.

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

On Fri, Apr 12, 2002 at 03:18:40PM -0400, Thomas H Hendrick wrote:
> I was thinking that it would be nice if we could include support for user-space
> programs to request that events (/dev/input/eventX) only be sent to a file
> descriptor when they are the foreground terminal.  I am going to play with this
> idea on my branch so it doesn't pollute the current devel code.  If we like it,
> we can merge when the time comes.
> 
> The idea is that the input_event struct provides all the wonderful information
> that programs will need.  However, between input and the user is some
> boiling/refining that removes some of the unnecessary information that probably
> 90-95% of all user-space programs don't care about.  For them, stdin/stdio takes
> care of all of their needs.
> 
> For that other 5-10%, the event device provides all the information you would
> need to do mouse, keyboard, etc.  However you will get ALL events destined for
> ALL consoles/terminals/etc, regardless of whether it was intended for you or vc
> 6 or the X-server or some x-term ... etc.

xterm? Uh-huh, how? xterms get mouse/keyboard data via the X protocol.

Actually a much more interesting project would be to write a console as
an userspace program connecting to /dev/pty's and using input and
framebuffers to implement all that's expected from a console. Including
nifty stuff like complete Unicode support, etc.

> I know by the end of 2.5.X I'm going to be nicknamed "The Ioctl Avenger" or
> something, but my current idea is to leave the devices are they are currently,
> and just add support for an ioctl, EVIOCCONSOLEONLY, which will signal to the
> event driver to only deliver events to a particular struct file when it is
> associated with the foreground console.  The rest is just adding the check to
> see if the pid of the file-owner is the same as the pid of the foreground vc
> owner before delivering the event.

I don't think this is a good idea. The app can filter that itself with
no problems, while it adds a lot of cruft into the kernel if implemented
there.

> There is one downside, however, that
> programs using the event device which may have more than one console open will
> not know which console the event occurred on, unless the input_event struct is
> changed to include a vc number - or- they open each event device multiple times,
> and register a different vc for each one.  There is a possible security risk,
> however, if I just let an program register to listen for events on any vt.  Not
> that it isn't a risk already, to some degree.  (A potential malcontent could ssh
> to a machine they have an account on, and use evtest to listen to the keyboard.
> They just need to look for KEY_EVENT "r" "o" "o" "t" "KEY_ENTER" "p" "a" "s" "s"
> "w" "o" "r" "d" KEY_ENTER.  Like I said, I'll play with it.

Actually, no. They should be root-readable only anyway, and root isn't
interested in his own password.

> 
> The alternative to the Ioctl idea was to add separate /dev/input devices that
> would be associated with particular terminals, but each input device would need
> a file associated with each terminal, and ... well, that's just ugly, IMHO.
> 
> Like I said, I'm gonna branch this so it doesn't pollute.
> 
> On the flip side of things, I'm hammering away on the user-space program to swap
> in keymaps.  I have implemented the full keymap ioctl's to transfer the keymap
> data all-at-once.  I will remove the older ioctl's, and test the newer ones once
> I get the user-space program finished.

Keep in mind that the keymaps will have different sizes and different
cell sizes as well. They may be 256 bytes or 512 shorts or anything else
on different keyboards.

-- 
Vojtech Pavlik
SuSE Labs

Re: Paper

[Brad H. <bh...@bi...>]

On Sat, 13 Apr 2002 07:27, James Simmons wrote:
> Hi!
>
>    I just placed in CVS a html version of a paper I plan to present at a
> talk in Ottowa soon. Have a look at:
>
> http://linuxconsole.sf.net/paper
>
> Yes lots is missing, I just started. I'm leaving the input section to you
> Vojtech to fill in.
I gave a paper at linux.conf.au in February, which has some stuff on the input 
layer with USB (since that is most people's experience with USB). You might 
be able to use some of the text or diagrams. See:
http://www.linux-usb.org/linux.conf.au.02/
for original KOffice formats and HTML renderings.

Brad

Paper

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

Hi!

   I just placed in CVS a html version of a paper I plan to present at a
talk in Ottowa soon. Have a look at:

http://linuxconsole.sf.net/paper

Yes lots is missing, I just started. I'm leaving the input section to you
Vojtech to fill in.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Console Support for event devices.

[Thomas H H. <wy...@at...>]

I was thinking that it would be nice if we could include support for user-space
programs to request that events (/dev/input/eventX) only be sent to a file
descriptor when they are the foreground terminal.  I am going to play with this
idea on my branch so it doesn't pollute the current devel code.  If we like it,
we can merge when the time comes.

The idea is that the input_event struct provides all the wonderful information
that programs will need.  However, between input and the user is some
boiling/refining that removes some of the unnecessary information that probably
90-95% of all user-space programs don't care about.  For them, stdin/stdio takes
care of all of their needs.

For that other 5-10%, the event device provides all the information you would
need to do mouse, keyboard, etc.  However you will get ALL events destined for
ALL consoles/terminals/etc, regardless of whether it was intended for you or vc
6 or the X-server or some x-term ... etc.

I know by the end of 2.5.X I'm going to be nicknamed "The Ioctl Avenger" or
something, but my current idea is to leave the devices are they are currently,
and just add support for an ioctl, EVIOCCONSOLEONLY, which will signal to the
event driver to only deliver events to a particular struct file when it is
associated with the foreground console.  The rest is just adding the check to
see if the pid of the file-owner is the same as the pid of the foreground vc
owner before delivering the event.  There is one downside, however, that
programs using the event device which may have more than one console open will
not know which console the event occurred on, unless the input_event struct is
changed to include a vc number - or- they open each event device multiple times,
and register a different vc for each one.  There is a possible security risk,
however, if I just let an program register to listen for events on any vt.  Not
that it isn't a risk already, to some degree.  (A potential malcontent could ssh
to a machine they have an account on, and use evtest to listen to the keyboard.
They just need to look for KEY_EVENT "r" "o" "o" "t" "KEY_ENTER" "p" "a" "s" "s"
"w" "o" "r" "d" KEY_ENTER.  Like I said, I'll play with it.

The alternative to the Ioctl idea was to add separate /dev/input devices that
would be associated with particular terminals, but each input device would need
a file associated with each terminal, and ... well, that's just ugly, IMHO.

Like I said, I'm gonna branch this so it doesn't pollute.

On the flip side of things, I'm hammering away on the user-space program to swap
in keymaps.  I have implemented the full keymap ioctl's to transfer the keymap
data all-at-once.  I will remove the older ioctl's, and test the newer ones once
I get the user-space program finished.

Happy Hacking,
--Tom.

============================================================
Thomas H. Hendrick
<wy...@at...>

Re: ruby : A bit simpler keyboard adding for multiple locale X servers

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

Okay. Added back in dummy consoel again for people that need it.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: ruby : A bit simpler keyboard adding for multiple locale X servers

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

> Here is dumb console driver created by me for X.

Hm. I see dummycon has come back to tease me. 

> Dumb console create VT and then do nothig.
> All work do linuxconsole vt-manager.
> You can configure dumb with kernel command line "dumbcon=x",
> where x is number of dumb consoles.
> Every console is binded with /dev/tty's depended from
> MAX _NR_USER_CONSOLES.

Hm. Go add about the number of VTs. 

> Sample:
> file vt_kern.h
> #define MAX_NR_USER_CONSOLES 4

MAX_NR_USER_CONSOLES is how many VCs per VT device. This is always 16.
MAX_NR_CONSOLES represents how many total VCs you can have. Dividing the
two you see wwe can have at most 4 VTs. 

> VGA configured, DUMB cofigured, command line "dumbcon=2" .
> 
> Result
> /dev/tty1 VGA
> /dev/tty2 VGA
> /dev/tty3 VGA
> /dev/tty4 VGA
> /dev/tty5 DUMB 0
> /dev/tty6 DUMB 0
> /dev/tty7 DUMB 0
> /dev/tty8 DUMB 0
> /dev/tty9 DUMB 1
> /dev/tty10     DUMB 1
> /dev/tty11     DUMB 1
> /dev/tty12     DUMB 1

It should be 

/dev/tty0 to /dev/tty15 VGA  /dev/tty16 to /dev/tty31 dummycon.
 
> This are tested by me with xdm, triple graphic login succesfully run.
> Edit /etc/X11/xdm/Xservers .
> Seems kdm, gdm don't like multiple X or wrong configuration on my end.
> X patch is necessary.

Can you post the patch :-)

> Q: Why linuxconsole vt-manager is better as separate keyboard driver for X.
> A: Linuxconsole project already have tons of keyboard drivers. All You can
> add to X
>      via /dev/tty.

Well XFree86 is currently based on using the VT. This will go away in the
future. I already have spoken to Jim Getty about this and he already is
working on making XFree86 independent of VT switching and to use the input
api!!! Yeah!!!!

Re: [Libff-devel] Sidewinder FF driver

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

> The point is that it seems we are having several versions of the hid 
> code. The version in Greg KH tree contained the right code. I hope Dave 
> Jones, Linus, Greg and us are not going to end up with different 
> versions. I fear the same problem applies to the rest of the code in our 
> CVS.

Only the USB code because it is so dynamic. I think the current approach
is tetsing new hid code is done here. Then passed to the USB guys which
then pass it up to Linus.

> Are we using the same kernel version ? I do have link-time errors too, 
> but not the same ones. In my case, handle_scancode isn't defined in any 
> object linked to bzImage.
> I was using Linus' 2.5.7 with files from the linuxconsole CVS in this 
> attempt.

handle_scancode. That shouldn't be used anymore. You wouldn't by change be
enabling keybdev.c in drivers/input. For ruby we don't need it anymore.

Re: [Libff-devel] Sidewinder FF driver

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

On Thu, Apr 11, 2002 at 11:48:07AM -0300, Rodrigo Damazio wrote:
> Fabien Brachere wrote:
> 
> >Rodrigo Damazio wrote :
> >
> >>Fabien Brachere wrote:
> >>
> >>>Ok, I didn't have an heart attack, and I put all this stuff on a very
> >>>minimal web site: http://madfab.free.fr/ff/index.html
> >>>
> >>>Fabien Brachere
> >>>
> >>        Nicely done...perhaps you'd like to help with the PID code? 
> >>Instead of registering itself for specific USB device IDs, it's a 
> >>subclass of the HID class, so whenever a HID device is detected, it 
> >>checks if it's also PID-compliant, and if it is then you can use force 
> >>feedback calls on it(this also allows us to not worry at all about 
> >>reading the axes input, since HID does that already)...the structs for 
> >>these calls are the very same that are used for I-Force, the only 
> >>difference is how we generate and send packets to the device...
> >>
> >
> >I know that the Sidewinder is registered by the HID module, but I'm not
> >satisfy with this: the joydev module report 24 buttons and 10 axes (it's
> >a big joystick but not so big ...), the only quick solution I found is
> >to short-cut hid by specifying USB device IDs, it's just for
> >development, I think we can see this later.
> >
>         That's indeed true...I wonder why that happens - is it the 
> joystick that reports itself as having all that, or is it a bug in the 
> HID code? I think it's too small of a thing to re-create the driver 
> though, it can probably be fixed...

Most likely some of the PID stuff gets assigned as buttons/axes, because
no better match can be found - there are fallbacks in the input<->hid
mapping code.

> >The first important thing is to implement correct upload effect to the
> >device memory, once uploaded it's trivial to play it.
> >
>         I know...that's what I'm working on...these last days I merged 
> parts of the code from Bjorn and added missing parts to it, so it 
> already detects all FF capabilities of the joystick...

-- 
Vojtech Pavlik
SuSE Labs

ruby : A bit simpler keyboard adding for multiple locale X servers

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

Hi
Here is dumb console driver created by me for X.
Dumb console create VT and then do nothig.
All work do linuxconsole vt-manager.
You can configure dumb with kernel command line "dumbcon=x",
where x is number of dumb consoles.
Every console is binded with /dev/tty's depended from
MAX _NR_USER_CONSOLES.

Sample:
file vt_kern.h
#define MAX_NR_USER_CONSOLES 4

VGA configured, DUMB cofigured, command line "dumbcon=2" .

Result
/dev/tty1 VGA
/dev/tty2 VGA
/dev/tty3 VGA
/dev/tty4 VGA
/dev/tty5 DUMB 0
/dev/tty6 DUMB 0
/dev/tty7 DUMB 0
/dev/tty8 DUMB 0
/dev/tty9 DUMB 1
/dev/tty10     DUMB 1
/dev/tty11     DUMB 1
/dev/tty12     DUMB 1

Now You can run first X with parameter vt4 $ X0 :0 vt4
second $ X1 :1 vt8
third        $ X2 :2 vt12

X0, X1, X2 are symbolic links to /usr/X11R6/bin/XFree86.
Of course any X server have separate config file( parameter -xf86config
file).

This are tested by me with xdm, triple graphic login succesfully run.
Edit /etc/X11/xdm/Xservers .
Seems kdm, gdm don't like multiple X or wrong configuration on my end.
X patch is necessary.

Q: Why linuxconsole vt-manager is better as separate keyboard driver for X.
A: Linuxconsole project already have tons of keyboard drivers. All You can
add to X
     via /dev/tty.

Files:
Makefile patch forgotten in home.
--- vt.c  Tue Mar 26 13:01:05 2002
+++ vt.c.changed    Fri Apr 12 09:31:22 2002
@@ -1606,12 +1606,15 @@
 #if defined (CONFIG_PROM_CONSOLE)
     prom_con_init();
 #endif
 #if defined (CONFIG_FRAMEBUFFER_CONSOLE)
     fb_console_init();
 #endif
+#if defined (CONFIG_DUMB_CONSOLE)
+    dumb_console_init();
+#endif
     kbd_init();
     console_map_init();
     vcs_init();
     return 0;
 }







START OF dumbcon.c
/*
 *  linux/drivers/video/dumbcon.c -- A dummy console driver
 *
 *  To be used for X
 *
 */

#include <linux/module.h>
#include <linux/types.h>
#include <linux/kdev_t.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/vt_kern.h>
#include <linux/init.h>

/*
 *  Dumb console driver
 */

#if defined(__arm__)
#define DUMMY_COLUMNS    ORIG_VIDEO_COLS
#define DUMMY_ROWS  ORIG_VIDEO_LINES
#else
#define DUMMY_COLUMNS    80
#define DUMMY_ROWS  25
#endif

#define MAX_DUMB_CONSOLES 8
static unsigned long dumb_num __initdata = 0;      /* disabled by default
*/
MODULE_PARM(dumb_num, "n");



static const char *dumbcon_startup(struct vt_struct *vt, int init)
{
    struct vc_data *vc;
    vc = (struct vc_data *) kmalloc(sizeof(struct vc_data), GFP_KERNEL);
    vt->default_mode = vc;
    vc->display_fg = vt;
    vt->default_mode->vc_can_do_color = 0;
    vt->default_mode->vc_cols = DUMMY_COLUMNS;
    vt->default_mode->vc_rows = DUMMY_ROWS;
    return "dumb device";
}

static void dumbcon_init(struct vc_data *vc)
{
    vc->vc_can_do_color = vc->display_fg->default_mode->vc_can_do_color =
0;
    vc->vc_cols = vc->display_fg->default_mode->vc_cols;
    vc->vc_rows = vc->display_fg->default_mode->vc_rows;
}

static int dumbcon_dummy(void)
{
    return 0;
}

#define DUMMY  (void *)dumbcon_dummy

/*
 *  The console `switch' structure for the dummy console
 *
 *  Most of the operations are dummies.
 */

const struct consw dumb_con = {
    con_startup:    dumbcon_startup,
    con_init:       dumbcon_init,
    con_deinit:          DUMMY,
    con_clear:      DUMMY,
    con_putc:       DUMMY,
    con_putcs:      DUMMY,
    con_cursor:          DUMMY,
    con_scroll_region:   DUMMY,
    con_bmove:      DUMMY,
    con_blank:      DUMMY,
    con_font_op:    DUMMY,
    con_resize:          DUMMY,
    con_set_palette:     DUMMY,
    con_scroll:          DUMMY,
};

int dumb_init(void)
{
        const char *display_desc = NULL;
        struct vt_struct *vt;
        vt = (struct vt_struct *) kmalloc(sizeof(struct
vt_struct),GFP_KERNEL);
        if (!vt) return 1;
        memset(vt, 0, sizeof(struct vt_struct));
        vt->kmalloced = 1;
        vt->vt_sw = &dumb_con;
        display_desc = vt_map_display(vt, 1);
        if (!display_desc) return -ENODEV;
     printk("Console: %s %s %dx%d\n",
                vt->default_mode->vc_can_do_color ? "colour" : "mono",
                display_desc, vt->default_mode->vc_cols,
          vt->default_mode->vc_rows);
        return 0;
}

int __init dumb_console_init(void)
{
        unsigned long i;
        for(i=0; i<dumb_num && i<MAX_DUMB_CONSOLES; i++ ) {
       if(dumb_init()) return 1;
        }
        return 0;
}

int __init dumbcon_setup(char *options)
{
        if (!options || !*options)
         return 0;
        dumb_num =  simple_strtoul(options, 0, 0);
        return 0;
}

__setup("dumbcon=", dumbcon_setup);

#ifdef MODULE
void __exit dumb_module_exit(void)
{
        /* release_vt(&vga_vt); */
}

module_init(dumb_console_init);
module_exit(dumb_module_exit);

MODULE_LICENSE("GPL");
#endif
EOF dumbcon.c

Regards
Aivils Stoss

Re: ruby Trouble with new hardware

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

> Hi
> Now I have KT266 chipset motherboard.
> I couldn't start my TNT2 (AGP) X sever.
> X will start, when after 1-4 seconds freezy.
> Any other X (PCI) run as nothing happen although X(AGP) freezy.
> System will not reboot.
> Tested open and closed source nvidia drivers, lots of BIOS setings.
> 
> Trouble only with linux-ruby.
> I don't use CVS ruby . Couldn't say which tree.
> 99.99% is from ruby-2.5.2
> 2.4.18 kernel patched.
> 
> No problems with older 440ZX chipset.
> 
> Can You get me tiny guidance of bug hunting?

Can you post the output of dmesg ?

Re: [Libff-devel] Sidewinder FF driver

[Rodrigo D. <cu...@uo...>]

Fabien Brachere wrote:

>Rodrigo Damazio wrote :
>
>>Fabien Brachere wrote:
>>
>>>Ok, I didn't have an heart attack, and I put all this stuff on a very
>>>minimal web site: http://madfab.free.fr/ff/index.html
>>>
>>>Fabien Brachere
>>>
>>        Nicely done...perhaps you'd like to help with the PID code? 
>>Instead of registering itself for specific USB device IDs, it's a 
>>subclass of the HID class, so whenever a HID device is detected, it 
>>checks if it's also PID-compliant, and if it is then you can use force 
>>feedback calls on it(this also allows us to not worry at all about 
>>reading the axes input, since HID does that already)...the structs for 
>>these calls are the very same that are used for I-Force, the only 
>>difference is how we generate and send packets to the device...
>>
>
>I know that the Sidewinder is registered by the HID module, but I'm not
>satisfy with this: the joydev module report 24 buttons and 10 axes (it's
>a big joystick but not so big ...), the only quick solution I found is
>to short-cut hid by specifying USB device IDs, it's just for
>development, I think we can see this later.
>
        That's indeed true...I wonder why that happens - is it the 
joystick that reports itself as having all that, or is it a bug in the 
HID code? I think it's too small of a thing to re-create the driver 
though, it can probably be fixed...

>The first important thing is to implement correct upload effect to the
>device memory, once uploaded it's trivial to play it.
>
        I know...that's what I'm working on...these last days I merged 
parts of the code from Bjorn and added missing parts to it, so it 
already detects all FF capabilities of the joystick...

Rodrigo

-- 
* Rodrigo Damazio
* cu...@uo.../rod...@po.../rda...@ls...
* ICQ: #3560450         Homepage: http://www.vros.com/cuddly/
* Engenharia da Computação / Laboratório de Sistemas Integráveis(LSI)
* Escola Politécnica - USP - São Paulo

ruby Trouble with new hardware

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

Hi
Now I have KT266 chipset motherboard.
I couldn't start my TNT2 (AGP) X sever.
X will start, when after 1-4 seconds freezy.
Any other X (PCI) run as nothing happen although X(AGP) freezy.
System will not reboot.
Tested open and closed source nvidia drivers, lots of BIOS setings.

Trouble only with linux-ruby.
I don't use CVS ruby . Couldn't say which tree.
99.99% is from ruby-2.5.2
2.4.18 kernel patched.

No problems with older 440ZX chipset.

Can You get me tiny guidance of bug hunting?

Aivils Stoss

Re: [Libff-devel] Sidewinder FF driver

[Fabien B. <fab...@fr...>]

Rodrigo Damazio wrote :
> Fabien Brachere wrote:
> 
> >
> >Ok, I didn't have an heart attack, and I put all this stuff on a very
> >minimal web site: http://madfab.free.fr/ff/index.html
> >
> >Fabien Brachere
> >
>         Nicely done...perhaps you'd like to help with the PID code? 
> Instead of registering itself for specific USB device IDs, it's a 
> subclass of the HID class, so whenever a HID device is detected, it 
> checks if it's also PID-compliant, and if it is then you can use force 
> feedback calls on it(this also allows us to not worry at all about 
> reading the axes input, since HID does that already)...the structs for 
> these calls are the very same that are used for I-Force, the only 
> difference is how we generate and send packets to the device...

I know that the Sidewinder is registered by the HID module, but I'm not
satisfy with this: the joydev module report 24 buttons and 10 axes (it's
a big joystick but not so big ...), the only quick solution I found is
to short-cut hid by specifying USB device IDs, it's just for
development, I think we can see this later.
The first important thing is to implement correct upload effect to the
device memory, once uploaded it's trivial to play it.

>         It's a reasonably big set of commands to implement, so I 
> estimate it should take about a month or two for it to be 100% 
> working...the Sidewinder will work sooner though, 'cause it has its own 
> memory management...but we'll have to implement memory management for 
> devices that don't have it...that'll be a hassle, specially since we 
> don't have a good way to debug the device's internal memory...but let's 
> leave that for later and get the Sidewinder working first...
> 
> Rodrigo
> 

I'm OK with this, when the sidewinder will work, we can add memory
management in a sub-structure.

Fabien 

Re: [Libff-devel] Sidewinder FF driver

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

Rodrigo Damazio wrote:
> Johann Deneux wrote:
> 
>> Rodrigo Damazio wrote:
>>
>>> [...] btw, I'm attaching a few minor but necessary fixes to 
>>> linux-console 2.5.7 code...also on line 749 of hid-core.c, you forgot 
>>> to change the parameters to hiddev_hid_event...I'm not exactly sure 
>>> how it expects the uref struct to be populated, so I'm leaving that 
>>> one to you...
>>>
>>
>> Neither do I. I will in turn leave this one to James. 
> 
> 
>        Seems like he corrected it already =c)
> 

Well, I actually fixed it after sending the mail (which never reached 
the list anyway, because of a mistyped address).
The point is that it seems we are having several versions of the hid 
code. The version in Greg KH tree contained the right code. I hope Dave 
Jones, Linus, Greg and us are not going to end up with different 
versions. I fear the same problem applies to the rest of the code in our 
CVS.

>>
>>> ------------------------------------------------------------------------
>>>
>>> diff -ru ruby/linux/drivers/char/consolemap.c 
>>> linux/drivers/char/consolemap.c
>>> --- ruby/linux/drivers/char/consolemap.c    Wed Mar  7 01:42:27 2001
>>> +++ linux/drivers/char/consolemap.c    Mon Apr  8 18:17:22 2002
>>> @@ -397,7 +397,7 @@
>>>  
>>>  extern u8 dfont_unicount[];    /* Defined in consolemap_deftbl.c */
>>>  extern u16 dfont_unitable[];
>>> -extern u16 dfont_num;
>>> +u16 dfont_num;
>>
>>
>>
>> This one shouldn't be necessary. dfont_num is indeed defined in 
>> consolemap_deftbl.c (a file generated by conmakehash). 
> 
> 
>        I see...but for some reason it would compile, but at link time 
> it'd complain about not finding that symbol...
> 

Are we using the same kernel version ? I do have link-time errors too, 
but not the same ones. In my case, handle_scancode isn't defined in any 
object linked to bzImage.
I was using Linus' 2.5.7 with files from the linuxconsole CVS in this 
attempt.

-- 
Johann Deneux

Re: Possible Interface Shortcoming with input.h/input.c

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

On Sat, Apr 06, 2002 at 04:18:32PM -0500, Thomas H Hendrick wrote:
> I've noticed while looking over the code for input.h and input.c, that there
> seems to be no method for performing control commands (ioctl's for example) from
> the user-side of things on the device-provider, only the device-handler.
> 
> The user can use ioctl on the general event device [/dev/input/eventXX]
> (evdev.o) to perform some general things, such as change the keymap and get the
> version number of the evdev driver.  However, some modules might benefit from a
> layered mechanism for ioctl to get down to the device-side of things through the
> input layer.  I don't know which, however.
> 
> In a nutshell:
> to "struct input_dev" in input.h:
> + int (*ioctl)(struct input_dev *dev, struct file* file, unsigned int cmd,
> unsigned long arg );
> 
> and export in input.c:
> + int input_dev_ioctl( struct input_dev *dev, struct file *file, unsigned int
> cmd, unsigned long arg );
> 
> This is an interface change, I realize.  Mostly this is up for discussion, and
> is not really a proposal, per se.
> 
> Now, what would this buy us?  The user could send ioctl commands to the device
> provider as well as the device-handler.  However, the question is, is there
> anything in the device provider that the user needs to access and control that
> we can't already?  The only thing that comes to mind is "Get Low-Level Driver
> Version" which is TOTALLY not worth adding interface changes for.  However, if
> anyone else can think of other device providers that could benefit from this, it
> might be a useful change.

If we'll need it, we'll add it. But this would mean that this ioctl
function (and the stuff it controls) can only be invoked from device
handlers that can handle ioctls. And that isn't good.

> At the very least, I'd like to hear people's thoughts on it.
> 
> Now, the immediate problem of loading the keymap from user space already solved,
> since the input_dev->keymap pointer points to the low-level keymap array.  We
> just need a util from user-space to spend a lot of time chewing some ioctl's.  I
> may, however, add an IOCTL symbol to evdev.c to transfer them in bulk, (or at
> least more than one key per syscall). 

You can if you wish, but the transfer time saved by that isn't probably
worth the time spent coding the new IOCTL. If you implement that, please
remove the original IOCTLs - I definitely don't want to have more than
one way of doing the same thing - it always introduces bugs and
confusion for programmers trying to write for the API.

> I can take care of the user-space util pretty easily. I'm not sure,
> however, if we can detect the keyboards in atkbd.c in order to provide
> the correct keymap for the keyboard being used automagically.

In the past, I experimented with AT-keyboard fingerprinting, which could
tell about 20 different keyboard types from each other. It's possible,
but it takes long time (a minute or so) to detect the keyboard type. And
it can never detect all keyboard types from each other, because for some
the fingerprints are identical.

Because of that, atkbd.c only detects some basic keyboard types and
stuffs that into the idproduct and idversion fields.

> input_dev->idbus = BUS_I8042;
> input_dev->idvendor = 0x0001;        /* Not useful */
> input_dev->idproduct = atkbd->set;    /* This tells us if it is extend(set 4),
> set 3 or set 2 */
> input_dev->idversion = atkbd->id;        /* This is the id reported by the port,
> and is 0xab83 for most */
> 
> You'd think the user would know what keyboard they were using, and could load it
> themselves, unless of course, their keyboard doesn't work natively /without/
> loading the keyboard.

There will always be a 'default' map - the one hardcoded in the module.
And it'll work for 99.999% of keyboards well enough for the user to type
and load a more appropriate map (with all the internet/multimedia keys
enabled) himself.

> Anyways, just some thoughts before I head to the grocery store.  ;)

-- 
Vojtech Pavlik
SuSE Labs