linuxconsole-dev

Re: Linux event interface XFree86 Input driver

[Zephaniah E\. H. <wa...@ba...>]

On Sat, Feb 15, 2003 at 11:20:51AM +1100, Brad Hards wrote:
> It is now up on the Linux Journal web site:
> http://www.linuxjournal.com/article.php?sid=3D6429
>=20
> Note, I haven't double checked it since publication.

Thank you again, this has proven absolutely invaluable for the keyboard
side of the patch.

I'm still waiting for a solution to the console also getting the events,
though the answers my head is giving back are not the ones I actually
want.

Zephaniah E. Hull.
>=20
> Brad

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

   "<green>From</yellow>"
   "Wow. The green word From is no longer yellow. That's deep, man."
 -- Marcus Meissner & Lars Balker Rasmussen in the Scary Devil Monastery

Re: Linux event interface XFree86 Input driver

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 7 Feb 2003 08:59, Zephaniah E\. Hull wrote:
> On Fri, Feb 07, 2003 at 06:25:02AM +1100, Brad Hards wrote:
> > On Fri, 7 Feb 2003 02:24, Zephaniah E. Hull wrote:
> > > hat combined with the lack of documentation on the evdev keyboard
> > > interface, and some real life distractions, made me forget about it for
> > > a little while.
> >
> > I wrote up some documentation on the event API - you need the March
> > 2003 issue of Linux Journal.
>
> Err, 2003?  Any chance of getting a copy of it before then?
It is now up on the Linux Journal web site:
http://www.linuxjournal.com/article.php?sid=6429

Note, I haven't double checked it since publication.

Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+TYfjW6pHgIdAuOMRAp7aAJ0SQm2zEGKFPDJ0Xvt8HJgeFttkvwCgvd4v
ymuck8ReFymKXlLWJsNTc+s=
=iKuA
-----END PGP SIGNATURE-----

radeon 9700 problem

[Gregor B. <gre...@ao...>]

hi!

I just tried the radeonfb driver in 2.5.60. 
When it starts I can see some msgs untik 
the radeonfb ist started then my monitor 
tells my he's out ofsync with:
FV:162.6 Hz and FH:85.4 KHz. 

The output is:

<4>radeonfb_pci_register BEGIN
<4>radeonfb: ref_clk=2700, ref_div=67, xclk=16600 defaults
<4>radeonfb: probed SDR SGRAM 131072k videoram
<7>radeon_get_moninfo: bios 4 scratch = 2000002
<4>radeonfb: ATI Radeon 9700 NE SDR SGRAM 128 MB
<4>radeonfb: DVI port no monitor connected
<4>radeonfb: CRT port CRT monitor connected
<4>radeonfb_pci_register END
<4>hStart = 664, hEnd = 760, hTotal = 800
<4>vStart = 491, vEnd = 493, vTotal = 525
<4>h_total_disp = 0x4f0063	   hsync_strt_wid = 0x8c02a2
<4>v_total_disp = 0x1df020c	   vsync_strt_wid = 0x8201ea
<4>post div = 0x8
<4>fb_div = 0x1f4
<4>ppll_div_3 = 0x301f4
<4>ron = 1024, roff = 23632
<4>vclk_freq = 2519, per = 844
<4>Console: switching to colour frame buffer device 80x30

I tried it with vga=normal and vga=791

Can anyone help me to solve this problem?  
Thanks in advance Gregor

What's the job of the input.agent?

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

Hi, Brad
>Zephaniah
>
>What's the job of the input.agent?
>
>PLEASE do send your patches upstream. That is my earnest interest.
>
>Brad


     If system have lots of input devices, some needs post install scri=
pts.
Sometimes automaticaly device file assign distrub system, because sytem=

have unchangeable config files (XF86Config).
     Some joystiks needs for attaching scripts. So kernel detect input
device, perform initializig, then set up environment and run hotplug.
environment variables:

ACTION=3D
PRODUCT=3D
NAME=3D
PHYS=3D

Now input.agent script parse this variables and perform user works.
If device pluged in ACTION=3Dadd, if removed ACTION=3Dremove
Rather Vojtech Pavlik might explain this beter.

Aivils ?toss=

HID quirk patch.

[Zephaniah E\. H. <wa...@ba...>]

This seems to have gotten lost somewhere amongst the noise, it adds a
quirk for my mouse, apparently they were not quite smart enough to just
use the second wheel axis for the second wheel.

I've been using it for a while with no problems.

(They don't make a mouse with even more buttons, if they do then it
should have a different USB device ID.)

Zephaniah E. Hull.

-- 
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

"I am ecstatic that some moron re-invented a 1995 windows fuckup."
        -- Alan Cox

Re: X evdev input patches, and a problem.

[Zephaniah E\. H. <wa...@ba...>]

On Sat, Feb 08, 2003 at 10:52:54AM -0500, Vladimir Dergachev wrote:
>=20
>=20
> On Sat, 8 Feb 2003, Zephaniah E. Hull wrote:
>=20
> > On Sat, Feb 08, 2003 at 10:29:02PM +1100, Brad Hards wrote:
> > > On Sat, 8 Feb 2003 21:52, Zephaniah E\. Hull wrote:
> > > > Something comes to mind, but to be blunt it is still a hack, and it
> > > > could easily result in a system with no keyboard at all if X crashe=
s.
> > > >
> > > > Throw in a fake event, that tells the keyboard driver to ignore
> > > > everything from that input device until it receives the command aga=
in
> > > > with a different value.
> > > >
> > > > I don't really like it, but at the same time I don't see anything o=
verly
> > > > better.
> > > I don't think that anything you do on the event interface should affe=
ct the
> > > keyboard interface.
> > >
> > > Why not a special "disable output' ioctl on the keyboard interface?
> >
> > Possibly quite feasible, however I don't know the details of the
> > keyboard interface, but I suppose if nobody else cares to do this,
> > then I suppose I will look into it.
> >
>=20
> I think a while ago somebody on the kernel proposed a patch whereby any
> device that had evdev opened was removed from sending events to the
> console layer.

A nice idea, but I explained why that is /exceedingly/ dangerous a
message or two ago, I would not suggest such a patch.

Zephaniah E. Hull.
>=20
>                     best
>=20
>                       Vladimir Dergachev

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

<VOICE MODE=3DPitr>
So, you are thinking am Communist ? Deal, Comerade !
</VOICE>
  -- Chris on ASR.

Re: X evdev input patches, and a problem.

[Vladimir D. <vo...@mi...>]

On Sat, 8 Feb 2003, Zephaniah E. Hull wrote:

> On Sat, Feb 08, 2003 at 10:29:02PM +1100, Brad Hards wrote:
> > On Sat, 8 Feb 2003 21:52, Zephaniah E\. Hull wrote:
> > > Something comes to mind, but to be blunt it is still a hack, and it
> > > could easily result in a system with no keyboard at all if X crashes.
> > >
> > > Throw in a fake event, that tells the keyboard driver to ignore
> > > everything from that input device until it receives the command again
> > > with a different value.
> > >
> > > I don't really like it, but at the same time I don't see anything overly
> > > better.
> > I don't think that anything you do on the event interface should affect the
> > keyboard interface.
> >
> > Why not a special "disable output' ioctl on the keyboard interface?
>
> Possibly quite feasible, however I don't know the details of the
> keyboard interface, but I suppose if nobody else cares to do this,
> then I suppose I will look into it.
>

I think a while ago somebody on the kernel proposed a patch whereby any
device that had evdev opened was removed from sending events to the
console layer.

                    best

                      Vladimir Dergachev

> Zephaniah E. Hull.
> >
> > Brad
> >
>
> --
> 	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
> 	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
> 	    CCs of replies from mailing lists are requested.
>
> }>No.  I just point out to troublemakers that I have an English degree,
> }>which means that I am allowed to make changes to the English language.
> }>(What _else_ could it possibly be for?)
> }Wow; in that case, my physics degree is *WAY* more useful than I
> }had thought.
> This just proves how useless a computer science degree is:  there is hardly
> any useful science involved at all.  I want my computer black magic degree!
> 	-- Victoria Swann, Jonathan Dursi, and D. Joseph Creighton on ASR
>

Re: X evdev input patches, and a problem.

[Zephaniah E\. H. <wa...@ba...>]

On Sat, Feb 08, 2003 at 10:29:02PM +1100, Brad Hards wrote:
> On Sat, 8 Feb 2003 21:52, Zephaniah E\. Hull wrote:
> > Something comes to mind, but to be blunt it is still a hack, and it
> > could easily result in a system with no keyboard at all if X crashes.
> >
> > Throw in a fake event, that tells the keyboard driver to ignore
> > everything from that input device until it receives the command again
> > with a different value.
> >
> > I don't really like it, but at the same time I don't see anything overly
> > better.
> I don't think that anything you do on the event interface should affect t=
he=20
> keyboard interface.
>=20
> Why not a special "disable output' ioctl on the keyboard interface?

Possibly quite feasible, however I don't know the details of the
keyboard interface, but I suppose if nobody else cares to do this,
then I suppose I will look into it.

Zephaniah E. Hull.
>=20
> Brad
>=20

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

}>No.  I just point out to troublemakers that I have an English degree,
}>which means that I am allowed to make changes to the English language.
}>(What _else_ could it possibly be for?)
}Wow; in that case, my physics degree is *WAY* more useful than I
}had thought.
This just proves how useless a computer science degree is:  there is hardly
any useful science involved at all.  I want my computer black magic degree!
	-- Victoria Swann, Jonathan Dursi, and D. Joseph Creighton on ASR

Re: X evdev input patches, and a problem.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 8 Feb 2003 21:52, Zephaniah E\. Hull wrote:
> Something comes to mind, but to be blunt it is still a hack, and it
> could easily result in a system with no keyboard at all if X crashes.
>
> Throw in a fake event, that tells the keyboard driver to ignore
> everything from that input device until it receives the command again
> with a different value.
>
> I don't really like it, but at the same time I don't see anything overly
> better.
I don't think that anything you do on the event interface should affect the 
keyboard interface.

Why not a special "disable output' ioctl on the keyboard interface?

Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+ROn+W6pHgIdAuOMRArcSAJ49ShEQIl6eD1b7Ro0YM2q/Q0vLCgCZAXAu
X63efqCDRSoAITnBiD4hj4Q=
=Dap7
-----END PGP SIGNATURE-----

Re: X evdev input patches, and a problem.

[Zephaniah E\. H. <wa...@ba...>]

On Sat, Feb 08, 2003 at 09:31:17PM +1100, Brad Hards wrote:
> On Sat, 8 Feb 2003 16:12, Zephaniah E. Hull wrote:
> > I don't see any way to tell the kernel that the keyboard events should
> > not also be sent to through the console layer, which means, for
> > instance, that hitting alt-F1 on the USB keyboard both gives the event
> > to X, and then switches the console.
> >
> > Without that piece, things are not overly usable, and I'm not sure how
> > to fix the problem.
> We can go back to adding in the compile-time option for keyboard support,=
 and=20
> not compile the keyboard driver. Of course, then we have to have X to hav=
e=20
> any keyboard support at all.
>=20
> Has to be a better way than that.
>=20
> Maybe we can do something hideous with the keyboard mapping on the keyboa=
rd=20
> driver, to map it to something that gets ignored.=20
>=20
> I'd like a cleaner solution though.

Something comes to mind, but to be blunt it is still a hack, and it
could easily result in a system with no keyboard at all if X crashes.

Throw in a fake event, that tells the keyboard driver to ignore
everything from that input device until it receives the command again
with a different value.

I don't really like it, but at the same time I don't see anything overly
better.

(One might argue that this event might be sent when the device is
opened, which would have some pros, and some cons.  The biggest would be
that running evtest on your only keyboard device would kill your console
until you can ssh over and kill the evtest.)

Zephaniah E. Hull.
>=20
> Brad
>=20

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

Hey, if you've mlock'ed more than your available memory, there's nothing
the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");
  -- Linus

Re: X evdev input patches, and a problem.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 8 Feb 2003 16:12, Zephaniah E. Hull wrote:
> I don't see any way to tell the kernel that the keyboard events should
> not also be sent to through the console layer, which means, for
> instance, that hitting alt-F1 on the USB keyboard both gives the event
> to X, and then switches the console.
>
> Without that piece, things are not overly usable, and I'm not sure how
> to fix the problem.
We can go back to adding in the compile-time option for keyboard support, and 
not compile the keyboard driver. Of course, then we have to have X to have 
any keyboard support at all.

Has to be a better way than that.

Maybe we can do something hideous with the keyboard mapping on the keyboard 
driver, to map it to something that gets ignored. 

I'd like a cleaner solution though.

Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+RNx1W6pHgIdAuOMRAqTJAJ0cGjW0wCAm0tT+U6aD1CvghYSPBgCfYxyO
1ENGIK8PnXjXyNLPYaeXkFA=
=QfWk
-----END PGP SIGNATURE-----

Re: X evdev input patches, and a problem.

[Zephaniah E\. H. <wa...@ba...>]

On Sat, Feb 08, 2003 at 12:12:07AM -0500, Zephaniah E. Hull wrote:
> The current patches, against X 4.2.99.4, are at
> http://people.debian.org/~warp/evdev/, please read the README first.

Err, renamed it to readme and /now/ it shows up, bloody Apache
'feature'.

Zephaniah E. Hull.

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

I could imagine that there might be some GPL project out there that
_deserves_ getting sued(*) and it has nothing to do with Linux.

                Linus

(*) "GNU Emacs, the defendent, did inefariously conspire to play
towers-of-hanoy, while under the guise of a harmless editor".

X evdev input patches, and a problem.

[Zephaniah E\. H. <wa...@ba...>]

The good news is that I have basic patches, that support just about
everything.

The keyboard support at this point has two problems, the first is that
there is no support for the bell, that is mostly because the bell is a
separate event device.  I consider this to be a rather minor problem.

The second is /much/ bigger.

I don't see any way to tell the kernel that the keyboard events should
not also be sent to through the console layer, which means, for
instance, that hitting alt-F1 on the USB keyboard both gives the event
to X, and then switches the console.

Without that piece, things are not overly usable, and I'm not sure how
to fix the problem.

The current patches, against X 4.2.99.4, are at
http://people.debian.org/~warp/evdev/, please read the README first.

Zephaniah E. Hull.

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

=2E..and the burnt fool's bandaged finger goes wobbling back to the fire.
  -- The Gods of the Copybook Headings, by Kippling.

Re: Linux event interface XFree86 Input driver

[Zephaniah E\. H. <wa...@ba...>]

Ok!  Status update!

The good news is, I have the most basic of support functioning.

I can start with the USB keyboard only, type on it, change video modes,
even change out of X.

And there are several pieces of bad news.

That's it, no support for setting the repeat, or anything dealing with
LEDs, or anything with bells or whistles.

In addition, when you switch out of X for some reason something is
catching in a tight loop, it stops as soon as I switch back to X,
however it is a rather nasty bug.

And, as the last bit, I need to go to sleep about an hour ago.

I don't have a patch ready, but I'll make one once I get the bug fixed,
and a few more features added (like repeat rate, LEDs, and properly
translating the keys that X and the input core have different symbols
for), a patch will be made.

(As a side note, the repeat rate setting and LEDs are precisely where I
will need to refer to the code provided, and any additional
documentation that could be provided.)

Zephaniah E. Hull.
(How the hell did I get pulled into X input device hacking? Someone?
Please?)

P.S.: I'm not subscribed to linuxconsole-dev, so anything not cced to me
will never be seen.

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

* james would be more impressed if netgod's magic powers could stop the
splits in the first place...
* netgod notes debian developers are notoriously hard to impress
        -- Seen on #Debian

Re: Linux event interface XFree86 Input driver

[Zephaniah E\. H. <wa...@ba...>]

On Thu, Feb 06, 2003 at 02:39:25PM -0800, Wayne Whitney wrote:
> On Thu, 6 Feb 2003, Wayne Whitney wrote:
>=20
> > Well, I am definitely interested, for one. I am currently using the pat=
ch
> > below, which I adapted from Miguel Freitas' very hackish patch
> > <http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/> to make it slightly l=
ess
> > hackish.  It works for me, although I haven't extensively tested it.
>=20
> I noticed that the patch I sent omitted the following comments from Miguel
> Freitas' original patch about licenses.  I am sorry about the oversight.

Er, erk.

Sadly, this code can never get into X.

Thankfully, I only need it for documentation reasons, not for lifting
code.

Otherwise there could be problems when it comes time for me to submit my
stuff upstream.

As a side note, the patches from me are against 4.2.99.4, NOT 4.2.3.

Zephaniah E. Hull.

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

<cas> Mercury: gpm isn't a very good web browser.  fix it.

Re: Linux event interface XFree86 Input driver

[Wayne W. <wh...@ma...>]

On Thu, 6 Feb 2003, Wayne Whitney wrote:

> Well, I am definitely interested, for one. I am currently using the patch
> below, which I adapted from Miguel Freitas' very hackish patch
> <http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/> to make it slightly less
> hackish.  It works for me, although I haven't extensively tested it.

I noticed that the patch I sent omitted the following comments from Miguel
Freitas' original patch about licenses.  I am sorry about the oversight.

Cheers, Wayne

diff -ur xc/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c xd/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c
--- xc/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c	2003-02-06 14:36:41.000000000 -0800
+++ xd/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c	2003-02-06 14:31:58.000000000 -0800
@@ -25,6 +25,47 @@
  */
 /* $XConsortium: std_kbdEv.c /main/4 1996/03/11 10:47:33 kaleb $ */
 
+/* 2001/01/14 Miguel Freitas <mi...@ce...>
+ *
+ * USB Keyboard to PC-AT Keyboard HACK
+ *
+ * Included routines from Linux Kernel to handle usb keyboard events.
+ * I don't know if there are any license issues here. Any code written
+ * by me in this file is under the terms of the GNU General Public
+ * License as described below.
+ *
+*/
+
+/*
+ * $Id: keybdev.c,v 1.3 2000/05/28 17:31:36 vojtech Exp $
+ *
+ *  Copyright (c) 1999-2000 Vojtech Pavlik
+ *
+ *  Input driver to keyboard driver binding.
+ *
+ *  Sponsored by SuSE
+ */
+
+/*
+ * 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 <vo...@su...>, or by paper mail:
+ * Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
+ */
+
 #include "X.h"
 #include "xf86.h"
 #include "xf86Priv.h"

Re: Linux event interface XFree86 Input driver

[Zephaniah E\. H. <wa...@ba...>]

On Fri, Feb 07, 2003 at 06:25:02AM +1100, Brad Hards wrote:
> On Fri, 7 Feb 2003 02:24, Zephaniah E. Hull wrote:
> > hat combined with the lack of documentation on the evdev keyboard
> > interface, and some real life distractions, made me forget about it for
> > a little while.
> I wrote up some documentation on the event API - you need the March
> 2003 issue of Linux Journal.

Err, 2003?  Any chance of getting a copy of it before then?
>=20
> I still have interest in using this under X (mainly to help with
> devices that have non-standard capabilities, rather than for a dual
> head) but time has been rather short lately. I'd encourage people to
> keep working on it.

What sort of non-standard capabilities?  My current use is my mouse,
which has two wheels, one click-able, as well as two side buttons.

Zephaniah E. Hull.
>=20
> Brad
>=20

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

<Mercury> Knghtbrd: Eww, find a better name, the movie sucked.. <G>
<Knghtbrd> Mercury: The engine is better than the movie

Re: Linux event interface XFree86 Input driver

[Brad M. <bmi...@ue...>]

Zephaniah

What's the job of the input.agent?

PLEASE do send your patches upstream. That is my earnest interest.

Brad

Re: Linux event interface XFree86 Input driver

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 7 Feb 2003 02:24, Zephaniah E. Hull wrote:
> hat combined with the lack of documentation on the evdev keyboard
> interface, and some real life distractions, made me forget about it for
> a little while.
I wrote up some documentation on the event API - you need the March 2003 issue 
of Linux Journal.

I still have interest in using this under X (mainly to help with devices that 
have non-standard capabilities, rather than for a dual head) but time has 
been rather short lately. I'd encourage people to keep working on it.

Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+QraPW6pHgIdAuOMRAmL6AJ0eH0WnumH30lH1R8V7/gN3KUFVAACgkfMw
R5IPXVKcIn9OXBuFx1AZVE4=
=7Hg2
-----END PGP SIGNATURE-----

Re: Linux event interface XFree86 Input driver

[Zephaniah E\. H. <wa...@ba...>]

On Thu, Feb 06, 2003 at 09:07:14AM -0800, Wayne Whitney wrote:
> On Thu, 6 Feb 2003, Zephaniah E. Hull wrote:
>=20
> > On Mon, Jan 27, 2003 at 10:31:17AM -0800, Wayne Whitney wrote:
> >=20
> > > Adreas Shuldei mentioned on lin...@li... th=
at
> > > you have been writing a patch to XFree86 for an Input driver using the
> > > Linux /dev/input/eventX interface.  As of November he indicated that =
the
> > > patch worked for point devices, and that you were working on keyboard=
s. =20
> >=20
> > [ . . . ]
> >=20
> > If there is solid interest in this, I can get the keyboard stuff working
> > and shove the patches upstream.
>=20
> Well, I am definitely interested, for one. I am currently using the patch
> below, which I adapted from Miguel Freitas' very hackish patch
> <http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/> to make it slightly less
> hackish.  It works for me, although I haven't extensively tested it.

Eww, that /is/ bad.

It is however perhaps the only user I have found for the interface in
question, so it will help me with the keyboard code /quite/ a bit.

I'm currently compiling a much newer X tree, once that is done and works
I'll start work on the keyboard patch.

Zephaniah E. Hull.

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

"Delivery anywhere in the world within thirty minutes or the second one's
 free." - "pizza box" art atop a Minuteman ICBM silo, Paul A. Suhler, RHF

Re: Linux event interface XFree86 Input driver

[Wayne W. <wh...@ma...>]

On Thu, 6 Feb 2003, Zephaniah E. Hull wrote:

> On Mon, Jan 27, 2003 at 10:31:17AM -0800, Wayne Whitney wrote:
> 
> > Adreas Shuldei mentioned on lin...@li... that
> > you have been writing a patch to XFree86 for an Input driver using the
> > Linux /dev/input/eventX interface.  As of November he indicated that the
> > patch worked for point devices, and that you were working on keyboards.  
> 
> [ . . . ]
> 
> If there is solid interest in this, I can get the keyboard stuff working
> and shove the patches upstream.

Well, I am definitely interested, for one. I am currently using the patch
below, which I adapted from Miguel Freitas' very hackish patch
<http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/> to make it slightly less
hackish.  It works for me, although I haven't extensively tested it.

Cheers, Wayne


diff -ru xc/programs/Xserver/hw/xfree86/common/xf86Config.c xd/programs/Xserver/hw/xfree86/common/xf86Config.c
--- xc/programs/Xserver/hw/xfree86/common/xf86Config.c	2003-01-26 12:09:35.000000000 -0800
+++ xd/programs/Xserver/hw/xfree86/common/xf86Config.c	2003-02-02 16:22:55.000000000 -0800
@@ -1076,6 +1076,24 @@
      xf86Info.kbdProc    = xf86KbdProc;
      xf86Info.kbdEvents  = xf86KbdEvents;
      xfree(s);
+  } else if (xf86NameCmp(s, "linuxevent") == 0) {
+     xf86Info.kbdProc    = xf86KbdProc;
+     xf86Info.kbdEvents  = xf86LinuxEventKbdEvents;
+     xfree(s);
+     s = xf86SetStrOption(inputp->commonOptions, "Device", NULL);
+     xf86Msg(X_CONFIG, "Keyboard: Protocol: linuxevent\n");
+     if (s == NULL) {
+	 xf86ConfigError("A \"device\" option is required with"
+			 " the \"linuxevent\" keyboard protocol");
+	 return FALSE;
+     }
+     xf86Info.kbdFd = open(s, O_RDWR | O_NONBLOCK | O_EXCL);
+     if (xf86Info.kbdFd == -1) {
+       xf86ConfigError("cannot open \"%s\"", s);
+       xfree(s);
+       return FALSE;
+     }
+     xfree(s);
   } else if (xf86NameCmp(s, "xqueue") == 0) {
 #ifdef XQUEUE
     xf86Info.kbdProc = xf86XqueKbdProc;
diff -ru xc/programs/Xserver/hw/xfree86/common/xf86Privstr.h xd/programs/Xserver/hw/xfree86/common/xf86Privstr.h
--- xc/programs/Xserver/hw/xfree86/common/xf86Privstr.h	2003-01-26 12:09:35.000000000 -0800
+++ xd/programs/Xserver/hw/xfree86/common/xf86Privstr.h	2003-02-02 16:22:55.000000000 -0800
@@ -59,6 +59,7 @@
     int			bell_pitch;
     int			bell_duration;
     Bool		autoRepeat;
+    int			ledsave;
     unsigned long	leds;
     unsigned long	xleds;
     char *		vtinit;
diff -ru xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c xd/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c	2003-01-26 12:09:39.000000000 -0800
+++ xd/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c	2003-02-02 16:22:55.000000000 -0800
@@ -34,12 +34,18 @@
 #include "xf86Priv.h"
 #include "xf86_OSlib.h"
 
+#define EV_LED		0x11	/* <linux/input.h> */
+#define LED_NUML	0x00	/* <linux/input.h> */
+#define LED_CAPSL	0x01	/* <linux/input.h> */
+#define LED_SCROLLL	0x02	/* <linux/input.h> */
+
+
 #define KBC_TIMEOUT 250        /* Timeout in ms for sending to keyboard controller */
 
 void
 xf86SoundKbdBell(int loudness, int pitch, int duration)
 {
-	if (loudness && pitch)
+	if (loudness && pitch && xf86Info.kbdEvents != xf86LinuxEventKbdEvents)
 	{
 		ioctl(xf86Info.consoleFd, KDMKTONE,
 		      ((1193190 / pitch) & 0xffff) |
@@ -51,16 +57,44 @@
 void
 xf86SetKbdLeds(int leds)
 {
+	struct s_output_event {
+ 	       struct timeval time;
+ 	       unsigned short type;
+    	       unsigned short code;
+    	       unsigned int value;
+	} output_event;
+
+    if (xf86Info.kbdEvents != xf86LinuxEventKbdEvents) 
  	ioctl(xf86Info.consoleFd, KDSETLED, leds);
+    else {
+	output_event.type = EV_LED;
+	output_event.code = LED_NUML;
+	output_event.value = (leds&(LED_NUM)) ? 1 : 0;
+	write( xf86Info.kbdFd, (char *)&output_event, sizeof(output_event));
+
+	output_event.type = EV_LED;
+	output_event.code = LED_CAPSL;
+	output_event.value = (leds&(LED_CAP)) ? 1 : 0;
+	write( xf86Info.kbdFd, (char *)&output_event, sizeof(output_event));
+
+	output_event.type = EV_LED;
+	output_event.code = LED_SCROLLL;
+	output_event.value = (leds&(LED_SCR)) ? 1 : 0;
+	write( xf86Info.kbdFd, (char *)&output_event, sizeof(output_event));
+
+	xf86Info.ledsave = leds;
+    }
 }
 
 int
 xf86GetKbdLeds()
 {
 	int leds = 0;
-
+    if (xf86Info.kbdEvents != xf86LinuxEventKbdEvents) {
  	ioctl(xf86Info.consoleFd, KDGETLED, &leds);
 	return(leds);
+    } else
+	return(xf86Info.ledsave);
 }
 
 /* kbd rate stuff based on kbdrate.c from Rik Faith <fa...@cs...> et.al.
@@ -177,6 +211,9 @@
   if (xf86Info.kbdDelay >= 0)
     delay = xf86Info.kbdDelay;
 
+/* FIXME: just returning so we don't mess with any other keyboards... */
+  if (xf86Info.kbdEvents == xf86LinuxEventKbdEvents)
+    return;
 
   if(KDKBDREP_ioctl_ok(rate, delay)) 	/* m68k? */
     return;
@@ -228,8 +265,10 @@
 void
 xf86KbdInit()
 {
+    if (xf86Info.kbdEvents != xf86LinuxEventKbdEvents) {
 	ioctl (xf86Info.consoleFd, KDGKBMODE, &kbdtrans);
 	tcgetattr (xf86Info.consoleFd, &kbdtty);
+    }
 }
 
 int
@@ -242,6 +281,7 @@
 		ioctl(xf86Info.consoleFd, KDSKBMODE, K_MEDIUMRAW);
 	else
 #endif
+    if (xf86Info.kbdEvents != xf86LinuxEventKbdEvents) {
 	ioctl(xf86Info.consoleFd, KDSKBMODE, K_RAW);
 
 	nTty = kbdtty;
@@ -255,13 +295,18 @@
 	cfsetospeed(&nTty, 9600);
 	tcsetattr(xf86Info.consoleFd, TCSANOW, &nTty);
 	return(xf86Info.consoleFd);
+    } else
+	return(xf86Info.kbdFd);
 }
 
 int
 xf86KbdOff()
 {
+    if (xf86Info.kbdEvents != xf86LinuxEventKbdEvents) {
 	ioctl(xf86Info.consoleFd, KDSKBMODE, kbdtrans);
 	tcsetattr(xf86Info.consoleFd, TCSANOW, &kbdtty);
 	return(xf86Info.consoleFd);
+    } else 
+	return(xf86Info.kbdFd);
 }
 
diff -ru xc/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c xd/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c
--- xc/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c	2003-01-26 12:09:47.000000000 -0800
+++ xd/programs/Xserver/hw/xfree86/os-support/shared/std_kbdEv.c	2003-02-02 16:22:55.000000000 -0800
@@ -30,6 +30,90 @@
 #include "xf86Priv.h"
 #include "xf86_OSlib.h"
 
+#define EV_KEY		0x01	/* <linux/input.h> */
+#define KEY_SYSRQ	99	/* <linux/input.h> */
+#define KEY_PAUSE	119	/* <linux/input.h> */
+
+
+static unsigned short x86_keycodes[256] =
+	{ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
+	 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+	 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
+	 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
+	 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
+	 80, 81, 82, 83, 43, 85, 86, 87, 88,115,119,120,121,375,123, 90,
+	284,285,309,298,312, 91,327,328,329,331,333,335,336,337,338,339,
+	367,294,293,286,350, 92,334,512,116,377,109,111,373,347,348,349,
+	360, 93, 94, 95, 98,376,100,101,357,316,354,304,289,102,351,355,
+	103,104,105,275,281,272,306,106,274,107,288,364,358,363,362,361,
+	291,108,381,290,287,292,279,305,280, 99,112,257,258,113,270,114,
+	118,117,125,374,379,259,260,261,262,263,264,265,266,267,268,269,
+	271,273,276,277,278,282,283,295,296,297,299,300,301,302,303,307,
+	308,310,313,314,315,317,318,319,320,321,322,323,324,325,326,330,
+	332,340,341,342,343,344,345,346,356,359,365,368,369,370,371,372 };
+
+static void handle_scancode(unsigned char scancode, int down)
+{
+	char up_flag = down ? 0 : 0200;
+
+	xf86PostKbdEvent(scancode | up_flag);
+}
+
+static int emulate_raw(unsigned int keycode, int down)
+{
+	if (keycode > 255 || !x86_keycodes[keycode])
+		return -1; 
+
+	if (keycode == KEY_PAUSE) {
+		handle_scancode(0xe1, 1);
+		handle_scancode(0x1d, down);
+		handle_scancode(0x45, down);
+		return 0;
+	} 
+
+	if (x86_keycodes[keycode] & 0x100)
+		handle_scancode(0xe0, 1);
+
+	handle_scancode(x86_keycodes[keycode] & 0x7f, down);
+
+	if (keycode == KEY_SYSRQ) {
+		handle_scancode(0xe0, 1);
+		handle_scancode(0x37, down);
+	}
+
+	return 0;
+}
+
+
+static void keybdev_event(unsigned int type, unsigned int code, int down)
+{
+	if (type != EV_KEY) return;
+
+	emulate_raw(code, down);
+}
+
+
+void xf86LinuxEventKbdEvents()
+{
+	struct s_input_event {
+	       struct timeval time;
+	       unsigned short type;
+   	       unsigned short code;
+   	       unsigned int value;
+	} input_event;
+
+	if (xf86Info.consoleFd != -1) {
+	  close(xf86Info.consoleFd);
+	  xf86Info.consoleFd = -1;
+	  close(2);
+	}
+
+	while(read(xf86Info.kbdFd, (char *)&input_event, sizeof(input_event)) == sizeof(input_event))
+	{
+		keybdev_event( input_event.type, input_event.code, input_event.value );
+	}
+}
+
 void
 xf86KbdEvents()
 {
diff -ru xc/programs/Xserver/hw/xfree86/os-support/xf86_OSproc.h xd/programs/Xserver/hw/xfree86/os-support/xf86_OSproc.h
--- xc/programs/Xserver/hw/xfree86/os-support/xf86_OSproc.h	2002-01-25 13:56:17.000000000 -0800
+++ xd/programs/Xserver/hw/xfree86/os-support/xf86_OSproc.h	2003-02-02 16:22:55.000000000 -0800
@@ -228,6 +228,7 @@
 extern int xf86KbdOn(void);
 extern int xf86KbdOff(void);
 extern void xf86KbdEvents(void);
+extern void xf86LinuxEventKbdEvents(void);
 #ifdef XQUEUE
 extern int  xf86XqueKbdProc(DeviceIntPtr, int);
 extern void xf86XqueEvents(void);

Re: Linux event interface XFree86 Input driver

[Zephaniah E\. H. <wa...@ba...>]

First off, I apologise for the delay in response, life has been
interesting.

On Mon, Jan 27, 2003 at 10:31:17AM -0800, Wayne Whitney wrote:
> Hello,
>=20
> Adreas Shuldei mentioned on lin...@li... that
> you have been writing a patch to XFree86 for an Input driver using the
> Linux /dev/input/eventX interface.  As of November he indicated that the
> patch worked for point devices, and that you were working on keyboards. =
=20

Correct.

> What's the status of your patch?

To be honest, I got side tracked after a /complete/ lack of response to
a request for tests, there did not seem to be much interest at that
point for some reason.

That combined with the lack of documentation on the evdev keyboard
interface, and some real life distractions, made me forget about it for
a little while.

> Could you possibly send me a copy of the
> latest patch?  I am interested in the same thing, to set up a multidesktop
> linux box--2 video cards, 2 mice, 2 keyboards for 2 users.  I imagine that
> other people would be interested in your patch, if you wanted to cc: =20
> linuxconsole-dev.

Actually, I just dumped it on http://people.debian.org/~warp/evdev/,
instructions in the README.

If there is solid interest in this, I can get the keyboard stuff working
and shove the patches upstream.

Zephaniah E. Hull.
>=20
> Thank you,
> Wayne
>=20
>=20
>=20

--=20
	1024D/E65A7801 Zephaniah E. Hull <wa...@ba...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

Christian Biblical literalists are trusting themselves to an archaic English
translation of a Latin translation of (help me here) Greek? Aramaic?  sourc=
e.
I wouldn't even trust a VCR manual to make it through that intact. - Dr. Dee

Re: ruby 2.5.59 snapshot

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

>On Thu, 2003-01-30 at 11:07, Aiv...@un... wrote:
>> Hi all
>>      Current linuxconsole.sf.net CVS will not normaly compile and run.
>> I made my own snapshot for inquisitive users.
>> http://startx.times.lv/ruby-2.5.59-20030130.diff.bz2
>> against linux-tree 2.5.59 kernel
>> fbdev are broken
>>
>> Aivils Stoss
>is it based on bk stable?

No. James Simmons do more in ruby CVS.
linuxconsole.bkbits.com has some global variables like vt_cons,
which made life harder. In ruby CVS I remove only utterly stupid
bugs and it run.

>do you have some hints for X drivers under 2.5
>(nvidia and may be others as well(i think the XF-4.3 doesn't compile
>under 2.5.x)

I do not have a hints. My test box with Voodoo3 works like under 2.4.XX .
I use same old xf86 4.2.0 binaries.

Aivils Stoss

Re: ruby 2.5.59 snapshot

[Svetoslav S. <ga...@st...>]

On Thu, 2003-01-30 at 11:07, Aiv...@un... wrote:
> Hi all
>      Current linuxconsole.sf.net CVS will not normaly compile and run.
> I made my own snapshot for inquisitive users.
> http://startx.times.lv/ruby-2.5.59-20030130.diff.bz2
> against linux-tree 2.5.59 kernel
> fbdev are broken
> 
> Aivils Stoss
is it based on bk stable?

do you have some hints for X drivers under 2.5 
(nvidia and may be others as well(i think the XF-4.3 doesn't compile
under 2.5.x)

svetljo

ruby 2.5.59 snapshot

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

Hi all
     Current linuxconsole.sf.net CVS will not normaly compile and run.
I made my own snapshot for inquisitive users.
http://startx.times.lv/ruby-2.5.59-20030130.diff.bz2
against linux-tree 2.5.59 kernel
fbdev are broken

Aivils Stoss