compiling LEWebcam drivers for linux about phd2 HOT 16 CLOSED

Hi,
You definitely need the Linux Kernel sources to compile modules - your 
distribution provides these as one or more packages for installation (including 
all the dependencies), and it should be as simple as running 'make module && 
make module_install' (might be some additional configuration needed afterwards 
e.g. to make udev aware of the new driver).
Which webcam are You interested in specifically?
Regards,

S. Elste

the spc900nc and family, as it stands, it appears that the leWebcam driver 
needs _WINDOWS_ defined for it to compile, so it appears that they don't work 
on linux in long exposure mode, or is there another way to get these cameras 
working in long exposure mode, perhaps via indi?  I couldn't see anything in 
the drivers that gives this information, the port setting stays greyed out when 
using v4l, pwc or indi drivers with the spc900nc.  The port setting also 
doesn't have any means to access linux based serial devices, so I'm guessing 
the long exposure functionality for these cameras doesn't work under linux.

It doesn't look like it should be particularly difficult to add the code but of 
course if these cameras already work and I'm just missing a setting I'd prefer 
not to reinvent the wheel :)

Regards,
Reggie.

Hi,
did You mod the spc900 for long exposure mode - like on Steve Chambers site 
(http://www.pmdo.com/)?
Well, neither the old pwc driver (Kernels 2.4 and 2.6 only, i think) nor the 
current uvc module 'know' about this; controlling the shutter via INDI should 
be quite easy, but You'd need to do the frame readout as well ... tricky.
Would be great if You could provide a link to those driver sources, i'd like to 
have a closer look at them.
Cheers,

Steffen

Yes I've done the long exposure mod :)  Which driver sources do you need links 
for?  The leWebcam drivers I mentioned are part of the openPHD sources (in 
extras), frame readout shouldn't be any different to how it is normally for 
long exposures.  

It's also possible to control the LX mod via the LED control pin apparently, a 
little hack to make the drivers recognise the spc900nc as a slightly different 
model but that allows the led control, this is easily controllable via setpwc 
:)  It's also possible to control some aspects of the long exposure mod via the 
microphone volume level register, I think it just needs a small IC added to 
boost the signal coming out of it and it's good enough for providing total usb 
control for lx and/or amp off :)

I'm quite interested to see what we can do with indi, I'd even go so far as 
bypassing indi and just putting lx support directly into the pwc/uvc/v4l side 
of openphd.

Oh dear,
i knew i'd seen 'LEWebcam' before - i simply tend to ignore all the extra stuff 
in PHD because it's almost exclusively Windows ... looking like a complete 
idiot now :-O

Hmm, if i had spare time available and were good at kernel hacking i'd probably 
try to modify the uvc driver to expose the long exposure mod via V4L(2), 
because it should work seamlessly with existing programs ... like OpenPHD for 
example.

But getting back to your original question - You'd have to port the driver to 
Linux, and since the underlying models have next to nothing in common 'porting' 
here means 'starting from scratch', methinks.
Cheers,

Steffen

p.s.: I'm going to have a closer look at the uvc driver ... who knows, maybe 
the task is doable even without being a regular kernel committer.

Unfortunately, I'm not a driver coder as such, I understand very much what's 
going on and roughly what needs to be done conceptually, it's putting it 
entirely into practice where I might fail.

Essentially, we need to do what happens under the windows version.  For lx, 
it's really just a simple case of opening a serial port and toggling rts.  The 
question is where to do it.  It would appear that for v4l/pwc straight driver 
capture is done via cam_VIDEODEVICE.cpp in a function called captureFull, so 
for hijacking purposes we could probably do something in there or in the 
get_frame/read_frame functions in linuxvideodevice.cpp.

If using the PWC driver via INDI then captureFull is in cam_INDI.cpp.  so in 
theory we should be able to cobble it in there somewhere, using the method in 
the cam_LEwebcam.cpp as a template.


There's probably 3 ways to go about the driver, as there are 3 methods for LX 
on the philips webcams, lxusb (usb control implementation), serial/parallel LX 
and the 3rd way is really a hybrid I'm thinking of.

To start off with I'd like to look at just the serial mod as I expect that is 
the simplest to do, it's simply setting and clearing rts/dtr pins at the 
appropriate moments.

the hybrid I'm thinking of involves merging a couple of mods I've seen that I 
haven't really seen used anywhere.  There's the mod that uses the microphone 
volume slider to generate a signal and there's also a mod that uses LED control 
to trigger long exposures.

Quick update, See attached files, search for '// Reggie' to see what I've 
changed (or diff it), I've managed to get long exposure working via the v4l 
driver interface in PHD without actually having to touch the v4l drivers.  It's 
a bit of a kludge right now because it's bolted into the main code and it 
doesn't care what camera is loaded, it will attempt to open a com port and 
toggle the rts/dtr pins at the right times, at the moment DTR is just following 
rts, as it's a proof of concept I just concentrated on getting long exposure 
working.

At the moment I've just poked some numbers in for the exposure delay, these can 
be supplanted by the proper values from the actual source code when I can work 
out how to get at the various bits of information from PHD itself. my little 
bit of math for working out the delay was:
ourDelay = ((duration * 1000)-(1000/fps)) - LE_readdelay (as defined in the 
brain menu)

Duration should be the value in the dropdown, where I have le read delay atm I 
made a mistake and only had 15 microseconds, you might want to play with that 
if it doesn't work.  might also need to set framerate to match the framerate 
that appears to work for me (others might work but are untested), so use setpwc 
-f10 before you start phd, then once the camera is connected via v4l(2) driver, 
open the camera dialog and set the exposure to 100, I have no idea whether it 
has any bearing on the situation but it doesn't seem to hurt.

Hi,
cool - nice work!
Jepp, it would be really cool to 'package' access/control of the different mods 
into one application or driver ... well, it shouldn't be that hard to do.

Steffen

Ha famous last words 'it shouldn't be that hard to do' :-)  Although I do 
agree, it shouldn't be hard, putting the exposure code in was easier than I 
thought it would be, it took a while to work out what was going on with phd, 
then the drivers but it was just a matter of googling some code to set/unset 
dtr/rts.  I guess it just needs an appropriate method for pulling relevant data 
from the various settings in phd, enabling the right parts in the gui and 
adjusting phd's indi interface to cope with lx webcams.  We need to find a 
method to id the webcams.

... more like infamous :-O
USB Devices are identified by VendorID and ProductID - that won't help to 
distinguish the modded and unmodded camera versions, of course.
But it's enough to slightly alter the camera settings menu e.g. by showing a 
'Enable long exposure' switch that enables additional elements like COM port, 
exposure time and the likes.

Steffen

infamous indeed!  As for identifying modded cams, I don't think it would be 
entirely possible unless people were prepared to change their PID and hack the 
pwc/v4l2 drivers to look for this new pid.  I think the best we can hope for is 
identifying potential cameras and at least enabling the read delay options in 
the menus, that's really all I need, we can always offer up a 2nd v4l interface 
possibly?

In most cases changing those IDs won't be possible because they're hardwired 
into the (single) IC that provides USB connectivity ...

Yeah, just a pid/vid list to identify the models that can be modded to make the 
additional settings visible; wouldn't be much different from a 'native' V4L 
solution apart from the fact that it's not provided by asking the driver for 
available parameters.

Steffen

Personally, I would do what's done on windows and offer up a long exposure 
version of the driver(s).  I could put a define in somewhere, or look at the 
cmake lists, that way people can compile it in if they want or just compile as 
normal if they don't need it.

You're right,
that would be a good solution - but most people are not used to compiling & 
installing drivers, and providing Binaries is next to impossible.
At least with .deb packages it should be possible to automatically build & 
install a driver (i've never tried that), including downloading the official 
source and applying the relevant patches beforehand.
Volunteers highly appreciated ... :-)

Steffen

I think that's the major issue with linux though, or possibly not, if you're 
going to use linux then essentially you are going to end up having to learn a 
small amount of programming of sorts and driver installation, along with 
patches too, its kind of unavoidable :D

In this instance I think it would be very easy because the modified code isn't 
actually in the driver, it's in phd's driver interface, so we could just 
provide another driver interface, very simply just lift all of the original 
source code for the v4l interface driver from phd, add LX to the function/class 
definitions as necessary, give it a unique name and offer it to the user as a 
camera driver choice when they click on the cam button.

So we wouldn't have to get them to touch any drivers, modify any code (as long 
as the code is in the main branch), just download the deb as usual or however 
you usually grab fresh apps.

I've been looking a bit more at how the long exposure works, the relationship 
between what the saa8116 chip, the nec 16510 chip, the ccd and phd looks like.  

Basically, all of the mods, the software relies on guesswork (very well 
educated guesswork of course!) or user intervention in the way of read delays 
to grab the correct long exposure frame.  I'm hoping that it's possible to find 
a more reliable method to grab the frame, perhaps I should start another thread 
for it?

Hi,
a new thread is a good idea - there's a 'Type-Enhancement' label available, 
which quite fits ;-)

Interesting idea - yeah, a camera driver that 'wraps' the original uvc (or pwc) 
driver and exposes the necessary settings for LE to work ... possible but still 
not easy because you then have to modify the udev subsystem to load the wrapper 
driver instead of the original; and that is Linux distro dependent (names of 
the configuration files, location; blacklisting has to be taken into account, 
read/write access as well because different groups are used; and let's not 
forget about SELinux).
Still, i REALLY like the idea because it would be transparent ... nice and 
clean.

Steffen

p.s.: I'm closing this issue - the original question is answered and we're 
going to discuss the stuff relevant to implementing LE elsewhere in detail.