Are you sure?
I remember setting things like IRQs and DMAs with jumpers 
What was the default for soundcards? IRQ7, DMA3, 220h?
Now I feel old…
5 Likes
Agreed, mostly you assigned IRQ/DMA with jumpers. The bios was
for onboard things, when they existed ( usually from 486 and up ) : serial and parallel ports, joystick, IDE.
Things like network cards, sound cards, modems, etc, had either jumpers or software utilities to set them. Some were fixed on some irq/dma, and would be inconvenient if the computer had another card with the same exigences.
That is just nonsense, SATA is perfectly hot-plug capable and there are enough desktop computers that expose SATA ports to the outer casing to connect drives.
(add tp that the obvious thundervolt case mentioned above. Or firewire or displayport or…)
3 Likes
I know that it’s generally a good idea to reduce duplication of effort/code, but is there any reason
to not have a one-time probe at boot for certain kinds of USB peripherals? Some devices definitely fall into a class where you’d expect it to be plugged in once and not removed.
Obviously, we still need Haiku to handle hot-plugging, but I think it’s probably okay to not worry about hotplug events that occur while the system is booting up as long as that is intentional and clearly documented behavior.
E.g.
- keyboard
- mouse
- boot devices (hard drive, cd drive flash drive – mass storage)
- printers
maybe also:
- sound devices (speakers, microphone)
- network devices (ethernet, wifi)
That is just nonsense, SATA is perfectly hot-plug capable and there are enough desktop computers that expose SATA ports to the outer casing to connect drives.
(add tp that the obvious thundervolt case mentioned above. Or firewire or displayport or…)
I think it’s probably safe to assume that USB is the use case of most immediate concern.
While SATA/eSATA is a thing, I believe it is rather uncommon for most end users to be hotplugging SATA devices. I would love to see Haiku support FireWire (FW) but I can’t see that it’s a real priority given that new computers haven’t come with it built-in for a long time and most devices are legacy products at this point.
DisplayPort seems like it would fall under detecting the monitors/displays that are attached and would be a similar concern as VGA or HDMI displays being connected after the system is booted up.
There are no reason to permanently save information about connected devices because discovering devices on each boot is fast enough. Adding permanent connected hardware information will only complicate things and increase a chance of various failures, but it will not save more than 0.1 seconds of boot time. Effort is not worth.
4 Likes
I wasn’t talking about permanently saved information, just proposing that there could be a single probe for connected USB devices at boot and no hot-plug detection at all until the system is completely up and running.
What problem are you trying to solve by disabling hot-plugging until “system is completely up and running”? Hot-plug events are usually zero-cost when it are not triggering. For USB for example hot-plug events can be detected using interrupts without any polling and this is how already my Device Manager v2 works.
8 Likes
I do not know the current state of the new device_manager.
My main interrest is for Intel GPUs. They offer the following functions:
- multiple monitors (eDP, DisplayPort, HDMI, DSI), up to 4
- multiple displays on a single DisplayPort connection (MST)
- audio via DisplayPort and HDMI
- Hot Plug Detection on Displayport and HDMI
- Video capture
- Video Codecs
While displays and audio outputs are plug and play, video capture and codec utilisation are not.
I think we should make sure those functions can be supported by the new device_manager.
@X512 I want to help you with the documentation and tests, I think it is very important for newcomers like myself to have a good guidance when developing a driver.
4 Likes
So, I’ve come across another thing that needs to be taken into account in a new API design (though it shouldn’t be too difficult to do so):
devfs mode types and permissions
Right now, devfs publishes all files as S_IFCHR. But this means that TTYs, /dev/random, etc. which are really S_IFIFO (that is, unseekable) aren’t detected and managed as such. Furthermore there isn’t any way to specify what permissions published devices should have.
1 Like
What is the current situation with the kernel device_manager? was anything decided? What are the next steps?
x512 is working on some code but has not sent anything for review on Gerrit.
I don’t think there are any reasons for someone else to work on a different implementation in parallel to that one.
2 Likes