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
13 posts were split to a new topic: BeOS on recent Mac hardware?
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?
Actually, intelspi is the name of the Linux driver. Under FreeBSD it is under sys/dev/intel/spi.c
but inside the haiku sources there is a draft driver, what is its working status? I know it’s disabled
For SPI? I haven’t seen anything similar in our source tree
sorry I was wrong with i2c
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.
There is some mention of this in the I2C thread here: Using new driver API - #78 by PulkoMandy
You may find the whole thread interesting, there is also some discussion of the new driver model.
That was already done. The HID stuff is currently a static library yo which the I2C and USB drivers are linked. No copypaste needed.
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!
Documentation for the new driver model is here:
It could be complemented with some extracts from existing driver code to be more self-contained.
Documentation for the old driver model is available in the Be Book.
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?
OK, clearly my knowledge was out of date, that is good to know.
That is documented in the document linked above:
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:
If your touchpad is i2c, that should already be covered here. For SPI you would need a new entry for scanning SPI busses.
For a sample driver, you can look at the ACPI power ones, which are a good simple example: