Hi,
I've looked at this before (it is actually why I
subscribed to this list
in the first place.) and am familiar with Miguel's work.
Technical matters aside, I came to the conclusion that
the major issue
standing of in the way of integration with the main tree is
one of
licenses.. that is to say that Miguel's patch is released
under a GPL
license, a license inherently unable to be re-integrated
with code
under the X consortium's license. I attempted to contact
Miguel, to see if
he might release his code under a different license, but
never heard back
from him. The point may be moot anyway, as I believe his
hack uses code
copied from the linux kernel (or at least their headers..)
specifically
the mentioned USBev interface. (which he did not in-fact
create. USBev
is a product of the linux-usb project (SuSE Labs), and is a
generic usb
event interface. [There's actually more to it than that..] )
The console code, as you mentioned is very nastily tied
up with the
Xserver still.. especially the keyboard driver, but this is
partially
because the linux kernel's new 'Input Method' structure has
not yet spread
beyond it's USB drivers, and the kernel Keyboard driver
itself is nastily
tied up with (the other side) of the console. The current X
keyboard
driver is clunky, but, short of migrating already arcane
code to a module
(not a small task..) there is no current alternative because
the kernel
back-end isn't there. Besides, you'd STILL wind up tied hand
and foot to
the console.
Miguel did a fairly nice job of removing the hooks from
the
console that the Xserver by default has. His USBev driver,
however is
short-sighted; He spliced his USBev keyboard support as
_a_replacement_ for the legacy keyboard driver, hardwired
in, rather than
writing it as a separate module (which could then be easily
(from a
technical standpoint) integrated with the main source tree.
This also does
little to aid in creating a unified binary to handle both a
separated
server and one tied to a console VT in the standard way.
I would still like to work on this, but am unclear as to
my liability
for licenses.. I have read Miguel's code... does this
prohibit me from
writing code that does a similar task without further
reference to his
work and releasing it in a less-restrictive license than the
GPL? If not,
how about the USBev headers in the Linux Kernel source; they
are the
definitive source for the #DEFINE's, the static's and the
struct{}'s
involved... definitions which _MUST_ be used in the code to
maintain
compatability or even basic functionality.... However THEY
most
definitely are GPL'd code.. how far is too far when it comes
to
referencing code (not even routines, just data structures
and
definitions) for inter-operability means? If this is a
simple RTFM, a
gentle shove in the right direction would be appreciated.
As for A. Mennuc!, I'd be more than willing to help you out,
My X hacking
is limited, but I think I understand a decent bit of this
microcosm.. I
would like to see the license issues resolved however, as a
patch,
especially under another license, tends to get left behind
if it doesn't
find it's way into a core repository, and at the very least
a good,
modular event Keyboard driver would be a nice contribution.
James Gibson
On Mon, 1 Oct 2001, A Mennucc1 wrote:
>
> hi
>
> (I send this same mail with a new subject; the old subject
was
> probably not attracting the attention of the interested
people)
>
>
> we would like to set up a cluster here and have 10
computers
> with 2 indipendent screens each, to allow two different
people
> to login together indipendently in each workstation:
> this would be really useful, since todays PC can easily
accomodate
> two users, and it would save a lot of money
>
> we have read the HOWTO
> http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/
> by Miguel Freitas <[EMAIL PROTECTED]>
> and are currently studying the patch
>
> as he says: "Unfortunately, the keyboard driver is still
deeply rooted at
> XFree86 core, it's not a separated module and
> access console I/O functions to read the scancodes.
Each XFree86
> instance would have their keyboard access
> halted by VT switching. "
>
> so Freitas' patch defines a new protocol for the keyboard
called 'usbev';
> the code also adds a '-delay' option, since it seems that
starting two X
> can sometimes locks the system;
> the patch also disables alle the code's references to the
console;
>
> this patch builds a
> different Xserver that can be used to start the second
screen
> (using an USB keyboard and a serial mouse or USB mouse ,
as input)
>
> we would like to change this patch
>
> we may implement this feature:
> add a new command line options, lets say '-noconsole'
> this options sets a flag in the structure 'xf86Info'
> that disables all the code referring to the console
swicthing
> as is done in patches M Freitas; the code that defines
the new 'usbev'
> keyboard protocol is instead probably ok as it is
>
>
> the final goal is to elaborate a patch that may be
accepted upstream
>
> Freitas' patch is only 469 lines long so it would not be a
prohibitive work
>
> what do you think?
>
> we havo no experience in hacking X : any help would be
greatly appreciated;
> our institution may even decide to hire someone fora short
term contract job
>
> a.
>
>
_____________________________________________________________________
// free anonymous email || forums \\ subZINE || anonymous browsing \\
subDIMENSION -- http://www.subdimension.com
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
