Driver adventures for a 1999 webcam(blog.benjojo.co.uk) |
Driver adventures for a 1999 webcam(blog.benjojo.co.uk) |
There are a number of possibilities that might need to be attempted.
In the lab I've got a 20-year old USB HP Laserjet printer plugged into an XP PC which is on my local LAN. Not a network printer but shared with other PCs over the LAN. This was a business printer and the newest drivers were for Windows 7 until the fairly recent Universal Print Driver packages from HP, where the UPD driver supports it with Windows 10/11 when you plug the printer into the USB socket of the W11 PC.
But with the printer plugged directly into the XP PC, then a W11 workstation on the same LAN (with all the permissions right and everything) could still find the printer but not the drivers. You could manually install the printer using the UPD drivers which appeared successful, but it would not print whether you selectied it as default or not.
It was necessary to log in to W11 as an administrator, unzip the old XP drivers, then in File Explorer point to the exact INF file for the exact printer, and right-click for the context menu to Install the INF manually in the background.
No compatibility mode needed, W11 just finds & uses the XP drivers when it connects to the printer after that.
Old Intel USB webcams from 1998 still just plug right in since they were Intel and it's still Windows.
When XP came out it was interesting because a W9x Intel webcam no longer needed drivers and even without any cam app the cam appeared as a device in File Explorer. When you clicked on it in the left-hand panel, the live video appeared in the right-hand panel. Now you need an app but IIRC the built-in modern Windows app may not work. Might have to use Amcap.exe or something more legacy-capable.
Old USB joysticks which were supported in W9x are configured using the same interface as their analog predecessors, and conveniently some modern joysticks can still be configured using the legacy interface (with greatly reduced features) without using the specific hardware driver.
v4l2-ctl might help you a lot.
Paper cuts like this is why the Linux Desktop isn't mainstream.
Plus, at the end of the day this hardware actually worked. This process would have been far more involved if the author was on Windows or Mac.
IIRC when I played with that 15-20 years ago qc-usb produced distinctly blurry images with slightly washed out colors, while the original windows driver produced images that are sharp, very noisy and with somewhat unnaturaly vivid colors.
Of note is that FFC --- and frequent too --- is basically mandatory for thermal imaging sensors, since their pixels drift a lot.
Some CMOS sensors or the surrounding electronics components on the PCB can heat up significantly while the sensor is in use.
If the sensor has a configurable gain (which is the hardware amplification applied before digitizing the voltage measured for each pixel), then you probably want to characterize the pixel-to-pixel variation for each gain level.
Long story short: the seller was a trustworthy fellow and definitely did not try to pull a fast one on me. What happened is that during assembly in the factory or a later repair someone smashed the lid into the main circuit board, almost but not quite tearing off one of those IDC headers for flat cable. Bits of it were rattling around in the case which already had me suspicious upon unloading it. That must have been quite the impact, those things don't normally break. The vibration of the transport across 200 km in a car with a stiff suspension did the rest and dislodged the cable completely. Plug the cable back in and it still worked, so I guess I got really lucky. It's been on the wall and has been making power for the last 3 days without any errors.
$ cat /usr/src/linux-headers-`uname -r`/include/uapi/asm-generic/errno.h | grep 90
#define EMSGSIZE 90 /* Message too long */
Nooo! errno from moreutils:https://man.archlinux.org/man/errno.1
$ errno 90
EMSGSIZE 90 Message too long
or: $ errno -s "too long"
E2BIG 7 Argument list too long
ENAMETOOLONG 36 File name too long
EMSGSIZE 90 Message too longUpdate the driver on my friends' computer (of course, without waiting a new kernel release) and boom, much better image from the camera! He was happy. He thanked me for how I fixed it, I thanked him for giving me opportunity for such a small and useful hack.
Got back to visit him a few days later. Noticed he wasn't using the webcam anymore. I asked "where's your webcam?", he said: "Damn webcam only works correctly under linux!"
I have an 2012 Logitech webcam connected to an OpenBSD box. A cron job instructs ffmpeg to read from /dev/video0 every 10 minutes, which in turn writes a .jpg into a folder for creating a timelapse. Not bad for a random old webcam I had laying around.
In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoints.
I was so happy when my Mac application was able to talk to the scanner and, compared to windows, completely without any driver installation thanks to user-space IOKit on macOS.
Writing software to make hardware beep is even more fun than writing software that doesn't involve hardware making noise.
This one has a simple answer:
USB is a shared bus and limited in bandwidth. Isochronous endpoints transmit continously and thus require a fixed part of that bandwidth.
The OS has to allocate the available bus bandwidth to all plugged in devices.
If no more bandwidth is available, it will refuse to configure the device that you just plugged in!
Thus the alternate setting with the isochronous packet size set to 0 serves multiple purposes:
1) It lets the OS configure the device and let the driver discover it even when not enough free bandwith is available on the bus
2) The driver can release the unused bandwith while the device is not in use
3) Not sending iso packets while the device is not actively used also means less power draw
There's no going back now- we've come too far. I can relate to this, though. I have it, so now I must solve it- pointlessness be damned.
...and that "eyeball on a stand" form-factor also became the de-facto one for a webcam (just image search "webcam icon"), so it is also historically significant from that perspective.
This is almost like the inverse of some efforts in the retrocomputing community, which involve writing drivers to allow new hardware to work with old OSs, among them Windows XP and the 9x series.
But I think the most frustrating reason to have to get rid of something is that drivers stop being made for devices.
...and they have a similar mindset: if there are no drivers, then let's write some.
On the topic of this particular camera, a little bit of searching shows some more information from a 23-year-old page:
http://www.geocities.ws/qcexpress/quickcam.html
...through which we get a hint that you can download the datasheet for the PB-0100 sensor from Photobit's site; although it is long gone, archive.org has saved some pieces:
https://web.archive.org/web/20001018065459/http://www.photob...
Sadly, the datasheets themselves weren't saved. I could find some for their later, larger sensors, but unfortunately not this one (although it may be out there, the increasing uselessness of search engines is a huge impediment --- and I do think that such destruction of access to historical information may in fact be deliberate.)
I cracked open (both out of curiosity and for recycling) my own 1999 Logitech QuickCam Express just a few days ago, then tossed away the parts. It was a decent webcam for the time, which was when Windows 98 was all the rage.
My desktop admittedly being a Windows system, I dabbled for a while trying to get the old drivers and software to work on Windows 11, alas, not a chance.
I liked the quirky thing especially for the physical visor that assured me nobody is watching me when the camera SHOULD be off, and saved me the masking tape (except for a single strip permanently glued to the inside of the visor, because for some odd reason, the thing was semi-translucent!)
I went out and bought a Trust webcam with Windows 11 support which astonishingly cost me less than three Euros (!!) new, at the bargain store. The Logitech, once upon a time, was more than ten times as much, not adjusted for inflation. Alas, the Logitech QuickCam had lower resolution, but still a better picture.
This was a very intreresting read, as I naively assumed that USB cameras had to follow some HID-like standard also for polling images off of it, like a scanner's TWAIN driver model back in the days. It was enlightening to read that they indeed seem to have had a unique encoding not shared with other cameras.
The driver support makes it a lot easier to build Franken-PCs with obscure graphics cards and accessories too. You wouldn't traditionally associate Linux with just working, but in the case of older hardware it is an amazing selling point.
Add to this many people now going to pains to do open source for closed (and sometimes abusive) platforms, which has network effects, bringing and cementing more techies to closed, and leaving them oblivious to why and how we have the open things we still do.
This also has network effects in removing some hard-earned pressure on hardware developers to cooperate with open platform efforts.
There's an expression about wealth, which I'll rephrase something like: "The first generation earns it, the second generation preserves it, the third generation fritters it away."
There's also an expression: "The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants."
We could avoid a lot of needless abuse in the next several years (and questionable tree-watering), by more of us actively trying to preserve and even improve libre/open platforms now.
Any examples or evidence of this? Seems easier than me than ever to use Linux with all kinds of hardware
https://bugs.ghostscript.com/show_bug.cgi?id=706455
There is a workaround by manually editing a script to call gs in a different way, but the original way doesn't work and they won't fix it, and the script itself is from a package maintained by nobody.
The most important one is that it is cumbersome for the application that feeds the virtual camera to know whether its output is used at all - e.g. for power-saving. The correct solution is V4L2_EVENT_PRI_CLIENT_USAGE, but there is no way to use it e.g. from within a GStreamer pipeline or from a call to ffmpeg. You need something like v4l2-relayd, which is a separate application, that starts and stops the GStreamer pipeline based on such events.
Also, there is no way to implement controls (gain, resolution, color temperature, etc.) on the virtual camera that could be passed through to the app that feeds the camera.
There is also akvcam, but it implements image processing in the kernel, which is gross.
I recently picked up a Creative Labs webcam with an LPT and PS/2 connector (probably used for power). I wanted to try it out on a W98 machine, but this inspires me to even try and write a driver for it.
A computer with LPT I have, now i just need to find the time :)
LPT isn't a problem (besides the real memory access and something tells me it does) but PS/2... vood luck?
you wouldn't believe it but it's actually Shooting Stars playing RN
This was such a great read and took me back to the days when you had to figure out the right pin configuration on your modems and write device drivers for anything that was a bit fancy on Slackware.
Thanks for the nostalgia.
Like in this case, would it have made sense to recreate the driver in this way so that other owners of the same camera could have immediately tried it out in their browsers regardless of their operating system?
How OS-specific are most USB devices?
And really great write up too!
Then we could all use ps3 dualshock controllers wireless again on windows. It seems all the links to third party programs to make it work are virus infected.
Once read, it would send the barcode number as keyboard commands. It was a very tactile experience.
Is there a better way to implement this? They seem to use it for any non-standard feature. My laptop's keyboard uses the control endpoint to control the LEDs.
In the case of this barcode scanner all communication was done over the control endpoint though.
For black box devices, you can build/buy a bus snoop cable and hook that up to usbmon/Wireshark (eg sniff the Xbox Kinect protocol).
Percurnious devices will encrypt/sign their packets to make reverse engineering more difficult, if not impossible, but those are few and far between. You're already buying the hardware and that's the expensive bit, so as long as you've bought the hardware, DRM-style weirdness over USB is rare. Still exists, but most hardware I see these days just uses a generic driver like HID for input, or UVC for video, reducing the amount of snooping needed to make the basics work. Getting extra functionality (like special LEDs) working still requires snooping of the working Windows driver+program though.