------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.kde.org/show_bug.cgi?id=114684
------- Additional Comments From taupter gmail com 2006-05-02 10:28 -------
>From http://v4l2spec.bytesex.org/spec-single/v4l2.html#VIDIOC-G-FMT
"When the requested buffer type is not supported drivers return an EINVAL error
code on a VIDIOC_S_FMT attempt.". That's the way the current code is checking
formats. It currently supports RGB and YUV formats (including conversions).
Bayer or compressed pixel formats are not supported ATM cause I don't have a
card/webcam that has these pixelformats, so I can't test something against a
device I don't own, and patching without having means of testing the patch is
not very clever as it can worsen the situation for people who already have
working devices. If somebody has a device, develops a patch and it works, I can
test it to check if it doesn't change adversely already supported devices I'll
commit that code.
The "Workaround buggy driver" option doesn't clearly states it will force
device to operate in V4L2 _on_purpose_. Kopete does not run only in Linux; BSD
people use it and (hopefully) webcams will be supported, and when (and if)
Kopete4 runs on Windows it should support webcams there too, so this option
must be as much platform-agnostic as possible, and used only when things go
really wrong.
See, V4L should be dead a long ago but drivers are still developed using this
API (spca5xx), there's an "early" V4L2 (for pre-2.6 kernels) and a "new" V4L2
APIs. Only in the last 6 months V4L2 API got 6 new versions (from 0.8 to .13).
It's just a moving target as ALSA was before the 1.0 release. Right now they're
discussing in V4L mailing list about the _standard_api_ for
_compressed_formats_! Some drivers (the new pwc as an example) implement calls
that return values not conformant to either V4L and V4L2 expected values.
spca5xx driver, at least in my hardware (Creative Webcam NX Pro) treat
brightness and contrast as the _same_thing_. Putting lots of workaround in
Kopete's code is not the right way; we must fix what's wrong with Kopete code
and ask driver writers (as I already did and sent patches) to put things
according to the canonical APIs.
_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel
