Hyperion Entertainment Message Boards

By the why do you want to put your driver as a Kickstart module?

By the why do you want to put your driver as a Kickstart module?

My thought exactly!

As to what you need to do to make it a kickstart module, nothing special IIRC. There is a difference, i think, between a.kmod and a .library (.usbfd is a .library) although I'm not sure what that is, but you can add plain libraries to the kickstart .

I suspet there is still a bug in the code.

After OS boot, it was "kicked out" by hid.usbfd, so I raised the USBA_Priority Tag to 6. After that, XeroMouse stays with the mouse, all fine and dandy again.

6 ? 1 is sufficient!

The reason that it is being 'kicked' out by hid.usbfd is that you have week binding set (you copied it over from bootmouse code) this allows bootcode to be replaced by full blown code when the usb stack moves from reboot to fullboot mode.

This means you code will be initliased twice make sure that that wont break it. Or try removing the

stat = um->IUSBSys->USBSetInterfaceAttrs( um->Interface, USBA_FD_WeakBinding, TRUE,
TAG_DONE );


An see if it makes any difference.

broadblues wrote:The reason that it is being 'kicked' out by hid.usbfd is that you have week binding set (you copied it over from bootmouse code) this allows bootcode to be replaced by full blown code when the usb stack moves from reboot to fullboot mode.

Wouldn't a "week" binding be good for at least seven days?


/me goes back to his compiler now...

@alaban:

Kickstart module, because the mouse would be useless if you need to use the Early Startup. bootmouse.ubsfd isnt able to drive the mouse correctly. So it would be embarassing to change the mouse just to use the Early Startup.

And a user asked for it

@broadblues:

I would suspect this bug, too, IF there wasnt the interesting fact, that there are absolutely NO troubles as long as hid.usbfd is not active. Its sufficient when its there, it doesnt do any (visible) binding to the mouse. And these troubles are only on unplugging! You could use the driver (and the mouse) without any hassle, together with hid.usbfd, as long as it isnt unplugged. The next interesting part of the trouble

So, there is some interference which is not related to the library code directly. If there was trouble related to the library code, the troubles would come not only on unplugging, if hid.usbfd is active. The troubles should come, even if hid.usbfd is NOT active. At least if I re-plug the mouse several times. Well, this part works flawlessy now.

I can use a bootmouse and Xero mouse together in Early Startup and after full boot. Simultaneously. I can unplug and re-plug either of these mice, many times (I didnt count yesterday, but it felt like 100 times), use them simultaneously, unplug them, when I move them... absolutely no problem. The total freeze happens only when hid.usbfd is active. I just search for the cause, and I dont find any good cause for this in the rMouse code or my modified code.

There is good chance, that my code is at fault, but chances are good that hid.usbfd has a problem, too. Question is: which code has problems? I dont know. I can see my code, and it is as good as it gets now. The Expunge function was faulty, no question. It was changed, the troubles stay. What I cannot see, is the hid.usbfd code. But I can see that this code has problems. It should recognize the Xero mouse and utilize it with nearly all functions, but it doesnt.

The total freeze is a candidate for race condition, but I cannot see any part in the rMouse code, that could suffer this. Its totally passive.

Btw., I tried non-weak binding already. Was one of my first measures to test But as it doesnt change anything regarding the unplugging-freeze, I made it weak binding again and claim by VENDOR/PRODUCT now. Much easier to test new/future versions/drivers this way.

Kickstart module, because the mouse would be useless if you need to use the Early Startup. bootmouse.ubsfd isnt able to drive the mouse correctly. So it would be embarassing to change the mouse just to use the Early Startup.

But is it suitable for a bootmouse? The driver I mean not the mouse itself. My UCLogicDriver tablet is not for instance.

A bootmouse driver has no access to dos.library for example, if you store any preferences / settings you will not be able to load them. In my case this causes a crash (must look at that in case it's my fault for not dealing with the failure although I think I do).

You may need to make a cut down version xerobootmouse and have a seperate full blown xeromouse.

The fact that the presence of hid.usbfd causes your module to crash if uses as a kivkstart module, need not imply an issue with hid.usbfd, it may be that the pattern of some unitiised memory is different if it is present.

Try testing in normal non kicksatrt mode but with MUNGE set on the kernel boot line or with MemGuard

broadblues wrote:

Kickstart module, because the mouse would be useless if you need to use the Early Startup. bootmouse.ubsfd isnt able to drive the mouse correctly. So it would be embarassing to change the mouse just to use the Early Startup.

But is it suitable for a bootmouse? The driver I mean not the mouse itself. My UCLogicDriver tablet is not for instance.

It is (or, at least, it should, according to USB documentation).

A bootmouse driver has no access to dos.library for example, if you store any preferences / settings you will not be able to load them. In my case this causes a crash (must look at that in case it's my fault for not dealing with the failure although I think I do).

I know what you mean... but it doesnt need any user definable settings to save. The Xero (resp. its protocol) is VERY near to bootmouse protocol. I needed to alter only ONE member of the USBootmouseData structure to make it work. Actually, I added an "empty" member. After that, I added the #defines & checks for 4th and 5th button and I had to inverse the mouse wheel data (vertical). Thats all. Even the tilt wheel function worked without further modifications. The mouse is fully functional and doesnt need any special settings to do the work it is intended for.

I re-checked the code against any IDOS references. As expected, none. Same goes for standard c library functions. None found.

The fact that the presence of hid.usbfd causes your module to crash if uses as a kivkstart module, need not imply an issue with hid.usbfd, it may be that the pattern of some unitiised memory is different if it is present.

Try testing in normal non kicksatrt mode but with MUNGE set on the kernel boot line or with MemGuard

I will do. But Im absolutely NOT that certain, that my module is "crashing" (Im even not sure if its actually a crash. Its a total system freeze, so far). The thing is: unplugging works under all circumstances I was able to test. As long as hid.usbfd isnt present somewhere. It might even be that the problem stems from my configuration, which is not that usual in Amiga world. I just cant judge about this, as I dont know anything about the workings/problems of hid.usbfd. All I know yet is, that the system is working without ANY flaws, as long as the Xero isnt unplugged, if hid.usbfd is present. The system works fine all the time, even with lots of re-plug-cycles, if hid.usbfd isnt present.

I use it on a daily basis, and I use it right now

Ok, found the culprit...

It was indeed the driver, BUT it was not a crash, still. There was a safety measure missing. The driver code was called although all resources were freed already. Added a check for "TheEnd", so that the driver code isnt called when the mouse is disconnected and "InterfaceHandler" frees all resources. I will investigate which call within "MouseHandler" caused the total freeze and why. It shouldnt happen that such a call freezes debug output totally