Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Driver adventures for a 1999 webcam

blog.benjojo.co.uk

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Driver adventures for a 1999 webcam

#31

Post by disjunct »

superdisk wrote: post #24

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.

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.

Re: Driver adventures for a 1999 webcam

#32

Post by VikingIV »

julian_sark wrote: post #7

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 especiall…

I believe they now most do follow the UVC standard; however OP's Logitech camera was manufactured before that was established.

Re: Driver adventures for a 1999 webcam

#33

Post by smugma »

“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”

Re: Driver adventures for a 1999 webcam

#34

Post by patrakov »

yrro wrote: post #14

Ugh I wish v4l2loopback was in the upstream kernel...

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.

Re: Driver adventures for a 1999 webcam

#35

Post by jandrese »

elteto wrote: post #19
gsliepen wrote: post #16

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 sharp…

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!

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.

Re: Driver adventures for a 1999 webcam

#36

Post by marcodiego »

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!"

Re: Driver adventures for a 1999 webcam

#37

Post by jimmaswell »

elteto wrote: post #19
gsliepen wrote: post #16

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 sharp…

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!

That was my immediate thought too. The XP image definitely looked a lot better.

Re: Driver adventures for a 1999 webcam

#38

Post by jandrese »

1970-01-01 wrote: post #23

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

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.

Re: Driver adventures for a 1999 webcam

#39

Post by account42 »

elteto wrote: post #19
gsliepen wrote: post #16

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 sharp…

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!

Yeah, looks like the author took a random debayering filter and then called it a day.
Post reply on HN