XeroMouse & hid.usbfd could co-exist?

[ssolie]

There is information in the autodocs which state you must Obtain/Release every Interface you use for each Task/Process.

I'm not near my Amiga right now, but IIRC looking for an Obtain or Release section in the autodocs one would not find anything. It seems to me the documentation is located in the exec/GetInterface() autodocs section which is not an obvious place to search if you are not already familiar with the concept.

Sounds like something that should be added to the wiki to me...

We shouldn't be leaving such important concepts buried in autodocs/includes.

[whose]

@ssolie:

Indeed

@alaban:

I did the test with hid.usbfd running first. Its all ok if I plug in the Xero mouse (its detected, recognized and used), but still: right with unplugging it, the system freezes. Again, if I dectivate hid.usbfd, there are absolutely no problems (besides EHCI driven ports).

I did another test and used my two mice in Early Startup simultaneously, and there is absolutely no interference (besides the interferences of my hands ). I reconnect both mice several times within Early Startup, and there is still no problem at all. The system boots fine after this.

I would say, the driver is quite clean now. Expunge is ok, so this was not the culprit.

Regarding the comparison with your tablet: Does it establish TWO devices of the same kind? The Xero does (I dont know what it is good for, but I see it in USBInspector and it is unused as long as the mouse is connected to an OHCI port). Maybe there is something going wrong with the "second device" and hid.usbfd.

Regarding the serial debug output: I have to search for the cable first, and if Im forced to alter UBoot settings, I have to wait for a new FlashROM first. My SAM is equipped with a rather strange UBoot, I cant use any keyboard with it and its missing any version information. Might be a beta version (the SAM is a used one...)

[abalaban]

@whose

No you don't *need* to change anything in UBoot: it's just easier to have it setup automatically there rather than being obligated to set it via a shell at each boot (you can use the user-startup though Look at the kdebug command line options in your SYS:Documentation drawer.

No my tablet does not present two USB interfaces, maybe you should try to either claim the whole USB Function (see USBSys/USBClaimFunction) either you should claim both interfaces (via USBSys/USBClaimInterface) that may be your problem, I don't know. Did you do reverse engineering to create your driver or did you base it upon other source code?

@ssolie

Sounds like something that should be added to the wiki to me...

In some way you already added it in the linked article... Maybe it just need a bit of highlighting.

[whose]

@whose

No you don't *need* to change anything in UBoot: it's just easier to have it setup automatically there rather than being obligated to set it via a shell at each boot (you can use the user-startup though Look at the kdebug command line options in your SYS:Documentation drawer.

Hehe, ok, will do...

No my tablet does not present two USB interfaces, maybe you should try to either claim the whole USB Function (see USBSys/USBClaimFunction) either you should claim both interfaces (via USBSys/USBClaimInterface) that may be your problem, I don't know. Did you do reverse engineering to create your driver or did you base it upon other source code?

I will try with claiming the 2nd interface, too. We will see

Regarding the data packets, I did some bus snooping on a Windows machine. Then I realized that e.g. hid class is a big mess. On the win machine, the mouse works, BUT the tilt wheel needs an extra driver!

The tilt wheel data is, if you step over the first data byte, which is always 0x20, just horizontal wheel data. No "big magic"

Seems that I should do some special USBInspector derivate for investigation on USB HID reports, too...

[whose]

I set up serial debugging now. It wasnt THAT easy, but I got it working using NVSetVar

Well, its useless for the unplugging-problem. I dont get any output from the USB stack over serial, it writes to T:usb.log all the time. I set the kernel debug level to 10 and I see lots of informational output, e.g. from sii3114ide...

I hope you people understand, that Im not interested in setting debuglevel=20 and drowning in debug output

[abalaban]

Ok so now that you have a serial debug setup, can you try to type in a shell :
newshell <>TCP:12345
this should let you have a shell waiting for input on TCP port 12345 (just an example port number, choose what you want, beware reusing standard port though)
After that try on the remote computer to connect to that TCP port, you should be able to see the shell and interact with it, for example listing directory etc.
The idea is that when your machine is frozen can you try to connect on this port from the remote computer and see if you can interact with the shell (which would mean that the system is *not* frozen, only the GUI is).

For my day to day debugging I use debug level 5 which is enough for standard things. However what I'm really surprised of is the fact you don't see the crash log on the serial output. Are you sure you told amigaos to output its debug to the serial port? see section 3 in Debug Kernel in the wiki.

[whose]

Ok so now that you have a serial debug setup, can you try to type in a shell :
newshell <>TCP:12345
this should let you have a shell waiting for input on TCP port 12345 (just an example port number, choose what you want, beware reusing standard port though)

Well... remember that I use an end user system here. TCP: just isnt working the way you desribed here and documentation about it is, as usual, VERY scarse. I wasnt able to connect, regardless which port number I tried. Windows firewall is inactive, nothing changed on Amiga side.

Anything else I might do to connect?

For my day to day debugging I use debug level 5 which is enough for standard things. However what I'm really surprised of is the fact you don't see the crash log on the serial output. Are you sure you told amigaos to output its debug to the serial port? see section 3 in Debug Kernel in the wiki.

Its definetly the serial port, as I see LOTS of debug output on my Windows machine terminal

But what if it isnt a CRASH actually, but a deadlock condition?

[whose]

Ok, I set up an AUX: shell and I got shell output, as long as I didnt pull the Xero.

As I suspected, its a DEEP freeze, deadlock condition. No chance to get any output. I will investigate further, disabling hid.usbfd and watching possible debug output from XeroMouse. I bet I will be able to get output, as long as hid.usbfd isnt active...

The problem starts as soon as I use XeroMouse as Kickstart module. Its based on the rMouse driver, so nothing special here, besides the Expunge problem, which is eliminated as cause now.

[abalaban]

The problem starts as soon as I use XeroMouse as Kickstart module. Its based on the rMouse driver, so nothing special here, besides the Expunge problem, which is eliminated as cause now.

Hmm, maybe there is something special to setup in order to be used as a Kickstart module, I don't know. I'll try to ask the relevant developers.

[whose]

Would be great, thx!