Subject: Re: Looking for wscons guru to help port-next68k
To: Michael Wolfson <michael@nosflow.com>
From: Lennart Augustsson <lennart@augustsson.net>
List: tech-kern
Date: 10/18/2003 23:12:53
But the X server already has code to read the wsmouse.  What's wrong
with that code?


Michael Wolfson wrote:
> Howdy,
> 
> der Mouse has modified the X server to work NetBSD/next68k 1.4T, but 
> doesn't know how to get wscons to read the keyboard and mouse devices 
> and send them to the X server.
> 
> He's added a driver to his kernel (1.4T) which handles this, but it 
> doesn't compile into a -current kernel.  So, if no one can help with 
> wscons, I suppose just knowing how to add special devices into -current 
> kernels would be sufficient.
> 
> TIA,
>   -- MW
> 
> Begin forwarded message:
> 
>> From: der Mouse <mouse@Rodents.Montreal.QC.CA>
>> Date: Fri Oct 17, 2003  10:59:23  PM US/Pacific
>> To: Michael Wolfson <michael@nosflow.com>
>> Subject: Re: Re:
>>
>> conf.c looks nothing like the file you're patching, and I don't
>>
>>> understand what it's doing anyways.
>>
>>
>> Oh, right.  They've completely rearranged how device drivers are hooked
>> into the special-device machinery.  I remember seeing that mentioned on
>> the lists.
>>
>> It's not obvious on a quick look what the correct way to hook a driver
>> into the special device machinery under the new world order is.  It
>> appears to have something to do with devsw_attach (kern/subr_devsw.c),
>> but that's not called anywhere in arch/next68k/*/*.[csh], so there's
>> obviously something I'm missing.  (Indeed, my grep just finished; it
>> seems it's not called anywhere in the kernel except from
>> kern/kern_lkm.c and lkm/netinet/if_ipl/mln_ipl.c, neither of which is
>> relevant to most devices, so I must confess myself completely baffled
>> as to how cdevsw gets set up.  Yet cdevsw_lookup(), as called from the
>> specfs open routine, uses cdevsw[], so it obviously must be set up.)
>>
>> You'll have to either figure out how device drivers rendezvous with
>> special device numbers and get the nk driver (the code the patches
>> added to nextkbd.c) connected to /dev/nk, or adapt the server to get
>> its input events through the drivers in place (wscons?), in order to
>> get the server working.  (I make no pretense that either part of this
>> will be easy, especially for someone who self-describes as not knowing
>> jack about coding.)
>>
>> Or, I suppose, drop back to an earlier kernel rev, something which
>> would carry its own prices.
>>
>>> nextkbd.c seems to have patched fine, but I can't figure out what
>>> device to create (when I run Xnext, it wants /dev/nk).
>>
>>
>> This is directly related to the trouble with conf.c.  Once you get the
>> special device stuff figured out, implicit in that will be figuring out
>> what major device number to use when creating /dev/nk.
>>
>>> Also, when it compiles, it barfs here:
>>
>>
>>> cc1: warnings being treated as errors
>>> ../../../../arch/next68k/dev/nextkbd.c:144: warning: type defaults to
>>> `int' in d
>>> eclaration of `cdev_decl'
>>> [...]
>>
>>
>> Well, aside from something having rather mangled these messages by
>> inserting incorrect line breaks, this is no surprise: cdev_decl() is
>> gone in the new world order of devices, and that's where the first
>> three messages come from - the compiler not surprisingly mistakes what
>> is intended to be a macro call for a function definition - and since
>> the declarations it is intended to provide are missing, that also
>> explains the "no previous prototype" gripes.  I expect these problems
>> to go away when (if) the special device issues are cleared up.
>>
>> /~\ The ASCII                der Mouse
>> \ / Ribbon Campaign
>>  X  Against HTML           mouse@rodents.montreal.qc.ca
>> / \ Email!         7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>>
>