Good afternoon!
I used to develop for BeOS back in the day but haven’t been developing for ages now. I am trying to gather as much information as possible as I would like to try to write a SPI driver for MacBook’s trackpad and keyboard.
I have started from the source code from freebsd (spibus and intelspi) and I would appreciate some guidance on the Haiku side.
I know there are two driver models, the old and the new one. The latter seems quite convoluted so I’m investigating the former which should not be completely new to me.
is the old model the same as BeOS? Is there any documentation available for Haiku?
is the old model worth to start with?
Is ACPI accessible in the old model? The SPI controller is only enumerated on ACPI and not directly on the PCI bus
Hi, I would go with the new driver model. A bit of warning: ACPI interrupts could maybe not work as expected.
I couldn’t find anything about intelspi at freebsd. Do you have links?
I believe in general for input drivers the Haiku architecture could be improved to pull out some of the HID stuff which is common between protocols. Though for now to get SPI going you may just want to cut and paste from the USB driver. Though that may be copy number three at least with USB and I2C I think. I don’t know about Bluetooth as it might not be far enough along but eventually it would also need this.
Hi @leavengood, one problem is that the topic is quite complex and I have not both the knowledge of Haiku internals and also solid skills as a driver developer, to be honest. But that’s ok, it is a challenge and I’m happy to cut my teeth on this. AFAICT we don’t have clear structured documentation on driver architecture and this could be an opportunity for me to learn, contribute and eventually document what I learned on the way.
Thank you for your response, I will look into that link. The purpose of this thread was to seek help and support from more experienced developers to let me start.
I think that i2c driver is a good starting point!
Thank you I have found the .rst file but it’s good we have a html version, too. It looks incomplete, though and it would be very useful to have a template driver with stub methods and structures.
Moreover, I understand that there are ad hoc changes required in device manager which are not documented as pointed out here, is it still the case?
Now, if the system requires disk access, it will scan the device file system for a driver that provides such functionality, in this case, it will look for drivers under “/dev/disk/”. The device manager has a set of built-in rules for how to translate a device path into a device node, and vice versa: every node representing a device of an intelligent bus (such as PCI) will also contain device type information following the PCI definitions. In this case, the “disk” sub-path will translate into the PCI_mass_storage type, and hence, the device manager will then completely explore all device nodes of that type.
The “set of built-in rules” mentionned here is what needs to be changed. You can find that here: