Menu
▾
▴
linuxconsole-dev
|
From: Zephaniah E\. H. <wa...@ba...> - 2003-02-08 05:13:14
|
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. |
|
From: Zephaniah E\. H. <wa...@ba...> - 2003-02-08 05:36:53
|
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". |
|
From: Brad H. <bh...@bi...> - 2003-02-08 10:44:15
|
-----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----- |
|
From: Zephaniah E\. H. <wa...@ba...> - 2003-02-08 10:53:31
|
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
|
|
From: Brad H. <bh...@bi...> - 2003-02-08 11:42:02
|
-----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----- |
|
From: Zephaniah E\. H. <wa...@ba...> - 2003-02-08 14:09:59
|
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 |
|
From: Vladimir D. <vo...@mi...> - 2003-02-08 15:52:57
|
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
>
|
|
From: Zephaniah E\. H. <wa...@ba...> - 2003-02-08 16:20:27
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X