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 */

https://man.archlinux.org/man/errno.1

  $ errno 90
  EMSGSIZE 90 Message too long

  $ errno -s "too long"
  E2BIG 7 Argument list too long
  ENAMETOOLONG 36 File name too long
  EMSGSIZE 90 Message too long

Update 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.

https://en.wikipedia.org/wiki/USB_video_device_class

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.

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.

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 :)

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?

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.