Hi,
My input in this regard is:
1) The new stack must be detach safe. I.E. no race conditions at detatch.
2) The stack must be able to take an arbitrary mutex, that is provided by the
low level device driver, and not just Giant.
--HPS
___
freebsd-hac
2007/4/17, Marcel Moolenaar <[EMAIL PROTECTED]>:
Thanks for detailed useful reply.
As for vtc(4): I've not been working on input devices because of the
lack of a generic layer. Note that vtc(4) deals with the low-level
console as much as it deals with user-visible terminals, so from that
point
On Apr 17, 2007, at 3:17 PM, Maxim Zhuravlev wrote:
2007/4/17, Marcel Moolenaar <[EMAIL PROTECTED]>:
Thanks for detailed useful reply.
As for vtc(4): I've not been working on input devices because of the
lack of a generic layer. Note that vtc(4) deals with the low-level
console as much as it
On Apr 17, 2007, at 10:21 AM, thIOretic wrote:
I would like to get info from everyone, who may take similar
efforts in FreeBSD input handling. I'm aware of
* newpsm framework
* KGI/KII
* vtc(4) was mentioned, but its code seems to do nothing from my
project thesis perspective. Or I've mi
Hi, hackers.
I'm working on 'Generic input device layer' GSoC2007 project
(http://wiki.freebsd.org/SummerOfCode2007). This mail is actually to introduce
my ideas and to synchronize it with current community efforts.
--Intro--
The project addresses input devices handling and multiplexing. The
5 matches
Mail list logo
