Hardware woes

Hardware woes

[Dave MacFarlane]

I'm trying to boot directly into 9front on my laptop instead of through a VM.

My laptop is a Asus TP300L Transformer Book, and it boots surprisingly
well from a USB key with the latest 9front.iso, but the trackpad is
messed up. Touching it makes the cursor teleport randomly around the
screen and randomly press buttons. I can just attach a USB mouse for
now, but I'd rather not. Does anyone have any pointers for where to
start looking into this?

Separately, I noticed that on the list of supported hardware it says:

"Intel Wireless-N 7260, does not work, but may not be hard to add to
existing etheriwl driver"

It's a Intel Wireless AC 7260 chipset in this laptop, so does anyone
have any more details about what "may" be involved in adding support
for the 7260 chipset that I can test out?

- Dave

Re: [9front] Hardware woes

[kokamoto]

> I'm trying to boot directly into 9front on my laptop instead of through a VM.
> 
> My laptop is a Asus TP300L Transformer Book, and it boots surprisingly
> well from a USB key with the latest 9front.iso, but the trackpad is
> messed up. 

most of trackpads are useless on Plan9, because of chordings of
mouse buttons in Plan9.
My CF-R7 can use trackpad, but useless.  My SONY vgn-vz31B cannot.
However, I don't mind it, because I can use 3 button usb mouse.

Kenji

Re: [9front] Hardware woes

[Dave MacFarlane]

I'm more concerned with the ability to point than the ability to
click. It just jumps around randomly and sends spurious clicks right
now.

I can use a kbmap which maps keyboard keys to emulate mouse clicks if
it points properly.

On Mon, Jun 27, 2016 at 7:31 PM,  <kokamoto@hera.eonet.ne.jp> wrote:
>> I'm trying to boot directly into 9front on my laptop instead of through a VM.
>>
>> My laptop is a Asus TP300L Transformer Book, and it boots surprisingly
>> well from a USB key with the latest 9front.iso, but the trackpad is
>> messed up.
>
> most of trackpads are useless on Plan9, because of chordings of
> mouse buttons in Plan9.
> My CF-R7 can use trackpad, but useless.  My SONY vgn-vz31B cannot.
> However, I don't mind it, because I can use 3 button usb mouse.
>
> Kenji
>



-- 
- Dave

Re: [9front] Hardware woes

[cinap_lenrek]

for the mouse, it seems that your trackpad is sending packets in
some strange way.

the ps2 mouse packets are processed in /sys/src/9/pc/mouse.c in the
function ps2mouseputc(), which gets called for each byte received
from the ps2 port. so putting a debug print at the start of that
function can reveal what we get. it might be just that you have
to specify "ps2intellimouse" at the "mouseport is" question
(defaults to ps2).

this wireless card probably needs a new driver, given that openbsd
made a new one (iwm(4)) for that card family. i have not looked
into this.

--
cinap

Re: [9front] Hardware woes

[Dave MacFarlane]

I've tried both ps2 and ps2intellimouse, and both have the same problem.

I added a statement to just print the parameters in ps2mouseputc
because I don't know what else is relevant, and this is what I get
from dragging my finger slightly to the right (is there a better way
to do this? Keeping in mind I don't have wifi on the machine so can't
just log it to a file to send..):

http://driusan.github.io/plan9/9frontmouse.jpg

(everything after the error message in the screenshot from unplugging
the usb mouse. I couldn't tell you what I was doing in the screenshot
before the error message. Something on the trackpad..)

On Mon, Jun 27, 2016 at 8:48 PM,  <cinap_lenrek@felloff.net> wrote:
> for the mouse, it seems that your trackpad is sending packets in
> some strange way.
>
> the ps2 mouse packets are processed in /sys/src/9/pc/mouse.c in the
> function ps2mouseputc(), which gets called for each byte received
> from the ps2 port. so putting a debug print at the start of that
> function can reveal what we get. it might be just that you have
> to specify "ps2intellimouse" at the "mouseport is" question
> (defaults to ps2).
>
> this wireless card probably needs a new driver, given that openbsd
> made a new one (iwm(4)) for that card family. i have not looked
> into this.
>
> --
> cinap



-- 
- Dave

Re: [9front] Hardware woes

[Dave MacFarlane]

Oh, I forgot to add.

The format of the log messages in the screenshot is just 'print("c: %x
(%d) shift: %x (%d)", c, c, shift, shift)'. (I forgot to put a newline
and didn't want to recompile a kernel and reboot again so it's a
little messy, but I can add a newline so it's a little cleaner if this
is unusable. I don't know what patterns I'm looking for, so I don't
know if there's anything obvious in this mess of data..)

On Tue, Jun 28, 2016 at 7:56 PM, Dave MacFarlane <driusan@gmail.com> wrote:
> I've tried both ps2 and ps2intellimouse, and both have the same problem.
>
> I added a statement to just print the parameters in ps2mouseputc
> because I don't know what else is relevant, and this is what I get
> from dragging my finger slightly to the right (is there a better way
> to do this? Keeping in mind I don't have wifi on the machine so can't
> just log it to a file to send..):
>
> http://driusan.github.io/plan9/9frontmouse.jpg
>
> (everything after the error message in the screenshot from unplugging
> the usb mouse. I couldn't tell you what I was doing in the screenshot
> before the error message. Something on the trackpad..)
>
> On Mon, Jun 27, 2016 at 8:48 PM,  <cinap_lenrek@felloff.net> wrote:
>> for the mouse, it seems that your trackpad is sending packets in
>> some strange way.
>>
>> the ps2 mouse packets are processed in /sys/src/9/pc/mouse.c in the
>> function ps2mouseputc(), which gets called for each byte received
>> from the ps2 port. so putting a debug print at the start of that
>> function can reveal what we get. it might be just that you have
>> to specify "ps2intellimouse" at the "mouseport is" question
>> (defaults to ps2).
>>
>> this wireless card probably needs a new driver, given that openbsd
>> made a new one (iwm(4)) for that card family. i have not looked
>> into this.
>>
>> --
>> cinap
>
>
>
> --
> - Dave



-- 
- Dave

Re: [9front] Hardware woes

[cinap_lenrek]

ok, this is useless. what you want is to log the c parameter only
which is the byte that was read.

so just print("%.2ux", c); should do. then dont send me screenshots,
but try to think about what you see, because i have no information
what you did to the mouse to identify what the bytes are. you should
determine the packet size first... like hold mouse steady, and then
toggle the buttons, and see how many bytes are printed... once you
have that you can try identifying where the bits are for the buttons...

there will not be a wireless driver soon, so plug the laptop on the
ethernet or change the card.

--
cinap

Re: [9front] Hardware woes

[Dave MacFarlane]

On Wed, Jun 29, 2016 at 3:13 AM,  <cinap_lenrek@felloff.net> wrote:
> ok, this is useless. what you want is to log the c parameter only
> which is the byte that was read.
>
> so just print("%.2ux", c); should do. then dont send me screenshots,
> but try to think about what you see, because i have no information
> what you did to the mouse to identify what the bytes are.

That's what I was afraid of, but I don't know what I'm looking for. What's
the expected output of, say, a left click? (It's probably still not very useful
with the noise, but the screenshot after the USB error was literally
just touching
the trackpad, moving about a millimetre to the right, then letting go.)

> you should determine the packet size first... like hold mouse steady, and then
> toggle the buttons, and see how many bytes are printed... once you
> have that you can try identifying where the bits are for the buttons...
>

Okay, but before I get to that my gut feeling tells me that resetmouse()
isn't setting the mode properly for a synaptics (the driver that Linux
says it's using for this) trackpad. It should just emulate a PS/2 mouse by
default according to the documentation that I found
(https://www.aquaphoenix.com/hardware/ledlamp/reference/synaptics_touchpad_interfacing_guide.pdf),
but that clearly isn't happening..

I gather the i8022auxcmd function sends a byte to the mouse. If I look
up the protocol to query the mode, can I just use that function to send
the appropriate byte(s) in resetmouse() and expect the response from
the mouse  to get printed? And is there any way I can send arbitrary
bytes from the command line without recompiling the kernel/rebooting?

> there will not be a wireless driver soon, so plug the laptop on the
> ethernet or change the card.

There is no physical ethernet port and I'm pretty sure the Intel card is a
SoC. Are there any USB network dongles that are known to work?
(Either wifi or ethernet)

- Dave

Re: [9front] Hardware woes

[stanley lieber]

On June 29, 2016 10:18:40 AM EDT, Dave MacFarlane <driusan@gmail.com> wrote:
>On Wed, Jun 29, 2016 at 3:13 AM,  <cinap_lenrek@felloff.net> wrote:
>> ok, this is useless. what you want is to log the c parameter only
>> which is the byte that was read.
>>
>> so just print("%.2ux", c); should do. then dont send me screenshots,
>> but try to think about what you see, because i have no information
>> what you did to the mouse to identify what the bytes are.
>
>That's what I was afraid of, but I don't know what I'm looking for.
>What's
>the expected output of, say, a left click? (It's probably still not
>very useful
>with the noise, but the screenshot after the USB error was literally
>just touching
>the trackpad, moving about a millimetre to the right, then letting go.)
>
>> you should determine the packet size first... like hold mouse steady,
>and then
>> toggle the buttons, and see how many bytes are printed... once you
>> have that you can try identifying where the bits are for the
>buttons...
>>
>
>Okay, but before I get to that my gut feeling tells me that
>resetmouse()
>isn't setting the mode properly for a synaptics (the driver that Linux
>says it's using for this) trackpad. It should just emulate a PS/2 mouse
>by
>default according to the documentation that I found
>(https://www.aquaphoenix.com/hardware/ledlamp/reference/synaptics_touchpad_interfacing_guide.pdf),
>but that clearly isn't happening..
>
>I gather the i8022auxcmd function sends a byte to the mouse. If I look
>up the protocol to query the mode, can I just use that function to send
>the appropriate byte(s) in resetmouse() and expect the response from
>the mouse  to get printed? And is there any way I can send arbitrary
>bytes from the command line without recompiling the kernel/rebooting?
>
>> there will not be a wireless driver soon, so plug the laptop on the
>> ethernet or change the card.
>
>There is no physical ethernet port and I'm pretty sure the Intel card
>is a
>SoC. Are there any USB network dongles that are known to work?
>(Either wifi or ethernet)
>
>- Dave

http://fqa.9front.org/fqa3.html

sl

Re: [9front] Hardware woes

[cinap_lenrek]

touching would indeed produce tons of noise. thats why i suggested you
press a button in an attept to produce a single packet response. but
i have no idea what your computer is like. there might not even be
physical buttons anymore.

your suspicion that it is in the wrong mode is plausible... the pc
mouse driver is not aware of any synaptic protocols. why the bios
set it to non-ps2 emulation mode is the question.

yes, i8042auxcmd() sends a raw byte to the mouse.

no, there is no driver to write the aux port from userspace,
tho you could make one with addarchfile() and writing a functions.

nusb/ether supports some chips as well as generic usb ethernet devices,
but i cannot guarantee if they will work. no real ethernet sucks, as
this also means it will be impossible to pxe boot this machine (very
convenient for writing drivers).

good luck.

--
cinap

Re: [9front] Hardware woes

[Dave MacFarlane]

I got home today ready to dig in and look into this more
systematically after reading
up about all the different modes for synaptic drivers, how to query
and set them, the weird
encoding they do to fit the extended commands into the standard PS2
protocol, etc, booted
into 9front, and.. it worked just fine.

It turns out the problem is that resetmouse() resets the PS2
properties, but the mode
had already been set by the Linux driver from PS2 mode to the absolute
mode where it
includes raw details about touch pressure, size, etc (which 9front is
misinterpreting as
arbitrary PS2 events).. a reboot isn't, technically, "powering on", so
it isn't resetting the
mode to the PS2 emulating default value that it comes up as with on a
cold boot, but leaving
it wherever the last OS left it. As long as I physically power off the
machine and turn it back
on, it works just fine.

On Wed, Jun 29, 2016 at 11:49 AM,  <cinap_lenrek@felloff.net> wrote:
> touching would indeed produce tons of noise. thats why i suggested you
> press a button in an attept to produce a single packet response. but
> i have no idea what your computer is like. there might not even be
> physical buttons anymore.
>
> your suspicion that it is in the wrong mode is plausible... the pc
> mouse driver is not aware of any synaptic protocols. why the bios
> set it to non-ps2 emulation mode is the question.
>
> yes, i8042auxcmd() sends a raw byte to the mouse.
>
> no, there is no driver to write the aux port from userspace,
> tho you could make one with addarchfile() and writing a functions.
>
> nusb/ether supports some chips as well as generic usb ethernet devices,
> but i cannot guarantee if they will work. no real ethernet sucks, as
> this also means it will be impossible to pxe boot this machine (very
> convenient for writing drivers).
>
> good luck.
>
> --
> cinap



-- 
- Dave

Re: [9front] Hardware woes

[cinap_lenrek]

you got it! excellent :-)

--
cinap

Re: [9front] Hardware woes

[Dave MacFarlane]

Okay, well, now I've got my choice of other hardware problems to try
and work on.

WiFi:
1. I've got one of these:
http://www.canakit.com/raspberry-pi-wifi.html gathering dust on a
shelf. The firmware in Linux is rt2870.bin (despite the chipset being
5390) and I noticed in /sys/src/9/pc/etherrt2860.c there's some code
about 2870, so figured there's a chance it'll just work. I plugged it
in and it's not even generating an event in /dev/usbevent. I know the
USB port works, because it's the same one I used to copy the firmware
into /lib/firmware. What would stop it from even noticing that the
dongle was plugged in?
2. I decided to look into the difference between the iwm driver from
OpenBSD (https://github.com/rpaulo/iwm/blob/master/driver/if_iwmreg.h)
and iwl from 9front
(http://www.9front.org/9front/sys/src/9/pc/etheriwl.c). From what I
can tell, every register and offset I compared seemed to have the same
format, so I'm tempted to just add the type to fwname[] and see what
happens. If that works, it'll be better than being forced to have a
usb port.. but I don't know how to figure out the ID for the type to
add to the enum above it. I added a print statement to setfwinfo() and
added ether0=type=iwl to my plan9.ini, but it doesn't seem to be
making it there. Is there something else I need to do to force the
driver or an easier way to probe the id?

Other:
3. 9front crashes whenever I plug in or unplug the power cable. I
assume there's a problem with the APM, but I can't seem to find where
that code lives.
4. I'm tempted to write a proper synaptic touch driver since the
packets seem to be pretty well documented, but the above are probably
more important..

On Wed, Jun 29, 2016 at 8:05 PM,  <cinap_lenrek@felloff.net> wrote:
> you got it! excellent :-)
>
> --
> cinap



-- 
- Dave

Re: [9front] Hardware woes

[cinap_lenrek]

> 1. I've got one of these:
> http://www.canakit.com/raspberry-pi-wifi.html gathering dust on a
> shelf. The firmware in Linux is rt2870.bin (despite the chipset being
> 5390) and I noticed in /sys/src/9/pc/etherrt2860.c there's some code
> about 2870, so figured there's a chance it'll just work. I plugged it
> in and it's not even generating an event in /dev/usbevent. I know the
> USB port works, because it's the same one I used to copy the firmware
> into /lib/firmware. What would stop it from even noticing that the
> dongle was plugged in?

the etherrt2860.c is driver for a pci card. usb drivers run in userspace.
so would need to port the wifi stack to userspace and make a usb driver.

> 2. I decided to look into the difference between the iwm driver from
> OpenBSD (https://github.com/rpaulo/iwm/blob/master/driver/if_iwmreg.h)
> and iwl from 9front
> (http://www.9front.org/9front/sys/src/9/pc/etheriwl.c). From what I
> can tell, every register and offset I compared seemed to have the same
> format, so I'm tempted to just add the type to fwname[] and see what
> happens. If that works, it'll be better than being forced to have a
> usb port.. but I don't know how to figure out the ID for the type to
> add to the enum above it. I added a print statement to setfwinfo() and
> added ether0=type=iwl to my plan9.ini, but it doesn't seem to be
> making it there. Is there something else I need to do to force the
> driver or an easier way to probe the id?

see iwlpci() function:

		switch(pdev->did){
		default:
			continue;
		case 0x0084:	/* WiFi Link 1000 */
		case 0x4229:	/* WiFi Link 4965 */
		case 0x4230:	/* WiFi Link 4965 */
		case 0x4232:	/* Wifi Link 5100 */
		case 0x4236:	/* WiFi Link 5300 AGN */
		case 0x4237:	/* Wifi Link 5100 AGN */
		case 0x423d:	/* Wifi Link 5150 */
		case 0x423b:	/* PRO/Wireless 5350 AGN */
		case 0x0082:	/* Centrino Advanced-N 6205 */
		case 0x0085:	/* Centrino Advanced-N 6205 */
		case 0x422b:	/* Centrino Ultimate-N 6300 variant 1 */
		case 0x4238:	/* Centrino Ultimate-N 6300 variant 2 */
		case 0x08ae:	/* Centrino Wireless-N 100 */
		case 0x0083:	/* Centrino Wireless-N 1000 */
		case 0x0887:	/* Centrino Wireless-N 2230 */
		case 0x0888:	/* Centrino Wireless-N 2230 */
			break;
		}

the device type is read from pci config space Rev register:

		ctlr->type = (csr32r(ctlr, Rev) >> 4) & 0xF;

the differences are distinguished by that field, like
the firmware name is indexed by that:

		fw = readfirmware(fwname[ctlr->type]);

--
cinap

Re: [9front] Hardware woes

[Dave MacFarlane]

On Fri, Jul 1, 2016 at 6:27 AM,  <cinap_lenrek@felloff.net> wrote:
> the etherrt2860.c is driver for a pci card. usb drivers run in userspace.
> so would need to port the wifi stack to userspace and make a usb driver.
>

So what's this code doing in in etherrt2860.c:

UsbDmaCfg = 0x02a0 /* RT2870 only */
[..snip more Usb prefixed variables..]

Or this:

enum {
FwBase = 0x2000,
Rt2870FwBase = 0x3000,
};

or this:

enum {
/* USB commands, RT2870 only */
Rt2870Reset = 1,
Rt2870Write2 = 2,
Rt2870WriteRegion1 = 6,
Rt2870ReadRegion1 = 7,
Rt2870EepromRead = 9,
};

?

- Dave

Re: [9front] Hardware woes

[cinap_lenrek]

nothing. this code defines constants, that are not used. it
got probably copied from the openbsd driver. theres really
no usb code in there.

--
cinap

Re: [9front] Hardware woes

[Dave MacFarlane]

> see iwlpci() function:
>
>                 switch(pdev->did){
>                 default:
>                         continue;
>                 case 0x0084:    /* WiFi Link 1000 */
>                 case 0x4229:    /* WiFi Link 4965 */
>                 case 0x4230:    /* WiFi Link 4965 */
>                 case 0x4232:    /* Wifi Link 5100 */
>                 case 0x4236:    /* WiFi Link 5300 AGN */
>                 case 0x4237:    /* Wifi Link 5100 AGN */
>                 case 0x423d:    /* Wifi Link 5150 */
>                 case 0x423b:    /* PRO/Wireless 5350 AGN */
>                 case 0x0082:    /* Centrino Advanced-N 6205 */
>                 case 0x0085:    /* Centrino Advanced-N 6205 */
>                 case 0x422b:    /* Centrino Ultimate-N 6300 variant 1 */
>                 case 0x4238:    /* Centrino Ultimate-N 6300 variant 2 */
>                 case 0x08ae:    /* Centrino Wireless-N 100 */
>                 case 0x0083:    /* Centrino Wireless-N 1000 */
>                 case 0x0887:    /* Centrino Wireless-N 2230 */
>                 case 0x0888:    /* Centrino Wireless-N 2230 */
>                         break;
>                 }
>
> the device type is read from pci config space Rev register:
>
>                 ctlr->type = (csr32r(ctlr, Rev) >> 4) & 0xF;
>
> the differences are distinguished by that field, like
> the firmware name is indexed by that:
>
>                 fw = readfirmware(fwname[ctlr->type]);
>
> --
> cinap


Okay, I ordered a wired usb dongle with a chipset that nusb/ether says
it supports and gave the IWL driver a quick shot while I wait for that
to ship. it seems that the driver differences aren't as trivial as I
hoped.

I added 0x081b to the switch and it's loading the driver now, but the
ctlr->type id (4) conflicts with the id for Type5150. Since I don't
really care about that chipset right now, I  replaced the firmware for
Type 4 with iwm-7260-9 and took out the references for checking if
Type (==/!= Type5150) throughout the code.

It's using the driver, but after the handover and poweron in iwlinit,
it's finding a bad rom signature.

I had a quick look at the poweron and handover code that preceed the
check in iwlinit, and while handover is pretty generic, there's a
couple chipset specific paths through poweron, so I tried changing:

if(ctlr->type != Type4965 && ctlr->type <= Type1000)

to:

 if(ctlr->type != Type4965 && ctlr->type != Type7620 && ctlr->type <= Type1000)

(Type1000 == 6, which is in an odd order right in the middle of 5xxx
and 6xxx Types, so from what I can tell that "if" statement is just
using an accidental ordering in the identifiers to target 5xxx
chipsets) Still no luck, so I think this requires actually figuring
out what the differences between the iwl and iwm drivers are to get
the 7260 to initialize properly. (I also tried going into the
ctlr->type == Type4965 statement a little further down with no luck.)

I'll probably stop looking into this here, but I figured I'd let
anyone else who wants to look into it know what I found. You're
probably right that it's best to port the iwm driver, even though
Linux manages to get by with a single Intel driver.

- Dave