[HN Gopher] Driver adventures for a 1999 webcam
___________________________________________________________________
Driver adventures for a 1999 webcam
Author : tomwas54
Score : 366 points
Date : 2023-04-28 11:33 UTC (11 hours ago)
(HTM) web link (blog.benjojo.co.uk)
(TXT) w3m dump (blog.benjojo.co.uk)
| gsliepen wrote:
| There is a lot you can do to improve the quality of the image.
| This camera has a very early CMOS sensor, which suffered from
| huge pixel-to-pixel variation. By characterizing each pixel
| (which you can do by taking dark field and flat field images),
| you can correct for this variation, and get an image that looks
| much less noisy. There are also various algorithms to undo the
| Bayer filtering, with tradeoffs between sharpness, color accuracy
| and performance.
| xattt wrote:
| Does pixel-to-pixel variation change based on temperature or
| some other ambient factor, or would characterization be a one-
| shot deal?
| bdigiifh wrote:
| In professional astronomy (where sensors are kept in dewars
| to reduce dark current) this process (flat field, dark field)
| is carried out at least once a night.
| gsliepen wrote:
| It is mostly the dark current (which is reflected in the
| values you would get if no light is hitting the CMOS sensor)
| which is affected by temperature. However, its effect scales
| with the exposure time. Since night time astrophotography
| requires long exposure times, this would require
| recalibration (see also @bdigiifh's post). However, for
| typical daytime use the effect is much less significant.
|
| 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.
| userbinator wrote:
| https://en.wikipedia.org/wiki/Flat-field_correction
|
| Of note is that FFC --- and frequent too --- is basically
| mandatory for thermal imaging sensors, since their pixels drift
| a lot.
| jacquesm wrote:
| That's a very neat trick. In two decades of messing around with
| webcams we never clued in to that, and I'm pretty sure that
| this may well be one of the reasons why we had noise issues
| when using our very early bluescreen implementation.
| elteto wrote:
| Maybe it's subjective, but the screencap from XP seems to show
| a much higher quality image. It seems there's still room for
| improvement. Awesome work regardless!
| account42 wrote:
| Yeah, looks like the author took a random debayering filter
| and then called it a day.
| jandrese wrote:
| He did say that the webcam had its gain and white balance
| controlled by the driver so I'm guessing he didn't go the
| extra mile to reverse engineer that part of the software for
| what is a pretty lousy camera.
| jimmaswell wrote:
| That was my immediate thought too. The XP image definitely
| looked a lot better.
| dfox wrote:
| The mentioned qc-usb driver seems to do some filtering.
|
| 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.
| userbinator wrote:
| _this was actually a pretty serious nostalgic moment as it
| happened to also be the same model as my first webcam_
|
| ...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.)
| emsixteen wrote:
| Cool read, but was a wee bit disappointing not to have it fully
| figured out by the end! That's just the reality of life though :)
| [deleted]
| joshu wrote:
| 1999 pffft. I have an original parallel port mono quickcam that i
| would like to use for partner meetings
| 1970-01-01 wrote:
| >This means that all attempts to get data from it using the first
| USB interface would fail. Now you might ask, why does the webcam
| have an endpoint with a 0 byte MaxPacketSize on its first
| interface? Who knows!
|
| Paper cuts like this is why the Linux Desktop isn't mainstream.
| [deleted]
| fetzu wrote:
| I am not sure I fully understand what you mean by your remark,
| but I am positive that this is not a situation most "mainstream
| desktop users" are ever going to encounter.
| DaanDL wrote:
| Yeah, I mean there are a lot of reasons why linux desktop
| isn't going mainstream anytime soon, but this is certainly
| not one of them.
| jandrese wrote:
| I'm pretty sure this is a quirk of the hardware that the Linux
| kernel has little control over.
|
| 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.
| cxcorp wrote:
| Is..is it not the webcam that's reporting the endpoint? Not
| Linux?
| duskwuff wrote:
| Correct. This is inherent to the camera's USB descriptor;
| it's entirely independent of the OS being used to interact
| with the device.
| cdelsolar wrote:
| I have an ElGato capture device that doesn't work with Linux -
| it's the one right before the model that does work but is
| significantly more expensive. Maybe this can help me write a
| driver for it ...
| rwmj wrote:
| $ 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 long
| superdisk wrote:
| I did something very similar quite recently with an old Mustek
| DV3000 camera that had webcam functionality. I was shocked to
| find out that Linux actually supports it out of the box. The
| quality is trash so it's not really usable, but fun messing
| around with it nonetheless.
| disjunct wrote:
| I have the cam in the article, and it worked off-the-shelf with
| my Linux box. I temporarily had it set up with a Raspberry Pi
| as a security cam.
|
| 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.
| jacquesm wrote:
| Linux support for old hardware is absolutely amazing. No matter
| how arcane or weird your gizmo is chances are someone wrote a
| driver for it that is still in support. This is one of those
| ways in which the open source world is way ahead of closed
| source, where you're sore out of luck even for relatively
| modern stuff (for instance: Firewire cards).
| wkat4242 wrote:
| Hah I knew it was that one. I had the same. Back in those days
| there were only a few models on the market. The quality was bad
| though and it was even black and white. This one is color so it
| must be a slightly later version.
| jacquesm wrote:
| Oh, the 'I took it home already' feeling. I had a really bad case
| of this last week, bought a 17 KW solar inverter for a relatively
| small amount of money and lugged it home, all 50 Kg of it. It
| worked when it was taken off the wall according to the seller,
| but on plugging it in on my end it didn't work, though the
| display lit up and it seemed to work it wasn't making any power.
| Normally you'd return it as defective and that would be that but
| this thing is heavy and it was far away.
|
| 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.
| ranma42 wrote:
| > Now you might ask, why does the webcam have an endpoint with a
| 0 byte MaxPacketSize on its first interface? Who knows!
|
| 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
| danlindley wrote:
| "This was especially annoying since I had already taken this
| thing home."
|
| 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.
| smugma wrote:
| "installing Windows XP on reasonably fast modern systems is very
| amusing, the setup wizard will say that it has 30 minutes
| remaining and then proceed to blow through the entire
| installation in less than 15 seconds"
| edgineer wrote:
| Reminds me of https://www.wired.com/2007/05/lone-programmer-
| writes-235-lin...
| Jiro wrote:
| "Writes drivers to allow 235 webcams to work" is not the same
| thing as "writes 235 webcam drivers".
| gregsadetsky wrote:
| I've been curious for a while - would it make sense for some USB
| drivers to be adapted / recompiled to WASM and used via web
| pages? (Chrome can allow JS code to access USB devices)
|
| 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?
| matheusmoreira wrote:
| Should custom USB drivers like this be contributed to the kernel?
| I wanted to send mine upstream but reading the source code I got
| the impression user space drivers are preferred. Would appreciate
| some guidance.
| pilif wrote:
| Reminds me when I had to read barcodes from a USB-connected
| barcode scanner on a Mac. The manufacturer supplied a closed-
| source library which only supported PPC code and they told me
| that they lost the source code, so I couldn't easily add intel
| support.
|
| 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.
| matheusmoreira wrote:
| > 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.
|
| 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.
| pilif wrote:
| you're supposed to use the control endpoint to negotiate
| which data endpoints to set up in what way for communication
| and then communicate over those.
|
| In the case of this barcode scanner all communication was
| done over the control endpoint though.
| xattt wrote:
| Core memory unlocked. Somewhere deep in the bellows of my
| electronics pile, I have an ancient HP barcode reader box that
| plugged inline with an AT keyboard. Into this box plugged a
| reader pen that you dragged across a barcode.
|
| Once read, it would send the barcode number as keyboard
| commands. It was a very tactile experience.
| yellowapple wrote:
| Meanwhile, USB barcode scanners nowadays work by basically
| being a keyboard, so I guess we've come full circle.
| sgrove wrote:
| That sounds pretty fun (once you're finished with it, I'm
| sure)! How does sniffing the USB work? Do you do that via some
| software/kernel extension, via special hardware, or something
| simpler? Do you find there are some USB devices where the
| manufacturer would rather you _didn 't_ sniff their traffic and
| make it more painful to piece together?
| neilv wrote:
| While Linux support for old hardware tends to be great, lately
| various kinds of Linux support are suffering in some ways, as
| higher percentages of software techies are now using Macs and MS
| Windows.
|
| 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_.
| mb7733 wrote:
| >While Linux support for old hardware tends to be great, lately
| various kinds of Linux support are suffering in some ways, as
| higher percentages of software techies are now using Macs and
| MS Windows.
|
| Any examples or evidence of this? Seems easier than me than
| ever to use Linux with all kinds of hardware
| Jiro wrote:
| Here you go.
|
| 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.
| martinmunk wrote:
| On a tangentant note, I've considered if it would be possible to
| gut the driver related parts (usb / Bluetooth subsystem ect) of
| linux and package it up to run as a userspace application in
| windows.
|
| 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.
| accrual wrote:
| This is pretty cool and impressive work! In a pleasant turn of
| events, "USB video device class" or UVC would have its initial
| release just 4 years later in 2003. Webcams implementing UVC,
| which most do since the early 2000s, communicate using a standard
| protocol which means almost any OS can access almost any webcam
| without any special drivers or software.
|
| 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
| mrguyorama wrote:
| Even better, this device class also covers things like cheap
| digital "microscopes" and external USB video capture devices.
| It really simplifies working with those kind of tools.
| gattilorenz wrote:
| Lovely!
|
| 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 :)
| justsomehnguy wrote:
| Holy shit!
|
| 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_
| gattilorenz wrote:
| I suspect PS/2 is only used to get 5V, so not really used by
| the driver
| marcodiego wrote:
| A friend of mine used a cheap (pac207) webcam. He complained to
| me that the camera image was too dark. I looked in the kernel for
| its driver... found the line which controlled its brightness...
| sent a patch to maintainer to increase. The maintainer accepted
| just a bit lower than what I suggest; he said that if the
| exposure was too long some protocol (probably USB) could break.
|
| 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!"
| martinmunk wrote:
| I have an old industrial thermal camera that takes pretty good
| pictures. But I don't have the xp software for it, and without a
| "known good capture" it's hard to reverse engineer and make it
| work on Linux.
| julian_sark wrote:
| Kudos!
|
| 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.
| roywashere wrote:
| If I recall correctly there was also a parallel port version of
| this webcam, for people using computers without usb support
| VikingIV wrote:
| I believe they now most do follow the UVC standard; however
| OP's Logitech camera was manufactured before that was
| established.
| anoncow wrote:
| I wonder if you could run it through Stable Diffusion as a next
| project idea? Train a model on your images using Dreambooth and
| then clean the video to get HD results?
| pizzaknife wrote:
| I have so many strange devices since my adventures in computers
| began. This has inspired me to dig them out of the plastic
| containers i have relegated them to and get some running again.
| Thank you for the write up!!!!
| vrglvrglvrgl wrote:
| [dead]
| bobsmooth wrote:
| I wonder if you could have gotten the webcam to work on Windows
| 10 by installing the XP driver under compatibility mode.
| reportgunner wrote:
| At first I thought the article was going to be a story of a young
| driver embarking upon an adventure to retrieve a webcam from
| 1999.
| peepee1982 wrote:
| Yeah, me too. Had my brain in knots for half a minute.
| yrro wrote:
| Ugh I wish v4l2loopback was in the upstream kernel...
| patrakov wrote:
| Well... actually for this use case we need something
| significantly improved. v4l2loopback has several flaws relevant
| to user-space camera drivers (which are also relevant to modern
| MIPI cameras).
|
| 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.
| anthk wrote:
| Linux has V4l-utils in order to set up some settings on any
| supported webcam (and TV tuner).
|
| v4l2-ctl might help you a lot.
___________________________________________________________________
(page generated 2023-04-28 23:00 UTC)