Unfortunately this struct is using non-const name field, but actually
may allow const in this case, because nobody's trying to free() these.
Until we've finally got a really clean solution, just do a typecast here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using the new driver build actions in X11Libre/actions-build-driver repo,
instead of having lots of duplicated pipeline and script in all the
individual driver repos.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The module directory has changed to a per ABI folder in the xlibre-xserver.
Now the default value of `xorg-module-dir` will be detected from the `moduledir` variable in xorg-server.pc.
Signed-off-by: b-aaz <b-aazbsd.proton.me>
This pipeline builds the driver against the latest Xserver stable
release as well as current master.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Add the following forms for issue creation:
* Bug report
* Feature request
* Code change
* Documentation update
* Organizational task
* add issue type selection page on "New Issue" call
* mention Github Discussions and the mailing list where appropriate
Part-of: X11Libre/misc#156
Signed-off-by: callmetango <callmetango@users.noreply.github.com>
v4l.c: In function 'AddV4LEnc':
v4l.c:920:16: warning: passing argument 1 of 'sprintf' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
920 | sprintf(enc->name,"%s-%s",norm,fixname(input));
| ~~~^~~~~~
In file included from v4l.c:20:
/usr/include/stdio.h:363:38: note: expected 'char * restrict' but argument is of type 'const char *'
363 | extern int sprintf (char *__restrict __s,
| ~~~~~~~~~~~~~~~~~^~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
AC_PROG_LIBTOOL was replaced by LT_INIT in libtool 2 in 2008,
so it's time to rely on it.
Clears autoconf warnings:
configure.ac:45: warning: The macro 'AC_PROG_LIBTOOL' is obsolete.
configure.ac:45: You should run autoupdate.
aclocal.m4:3551: AC_PROG_LIBTOOL is expanded from...
configure.ac:45: the top level
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
And expand the size to 18, because the stack array we copied this into is 18
bytes long. This covers us for up to 999 (kernel) v4l devices and that is
definitely not a reason to use the "640k ought to be enough" meme.
Found by - you guessed it - coverity!
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Coverity is unhappy and there's enough unhappiness in this world already, so
let's go for the low-hanging fruit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
We get this warning:
v4l.c:1154:39: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to remove the addressof? [-Wsizeof-pointer-memaccess]
It's correct enough, but ->cap is already zeroed by the previous memset.
Just remove the bogus one.
Fixes: xorg/driver/xf86-video-v4l#1
Signed-off-by: Adam Jackson <ajax@redhat.com>
If you're not using Linux, this isn't likely to build let alone run. And
if it _does_ build on non-Linux, it's probably because someone went out
of their way to try to make it work.
Signed-off-by: Adam Jackson <ajax@redhat.com>
video width/height size can vary not only as a function of the
video standard but also in function of device capabilities. Due
to that, the code were trying to get those info from the hardware.
However, due to a driver bug, the info is not properly filled when
the video standard is changed.
While I intend to fix this inside the drivers, the current logic
doesn't work with the current stable kernels. So, use an alternative
way of getting this info, just using video standards information.
Let's keep the not working code there, in order to make easy to
return, after fixing the drivers. We'll probably need to check for
driver versions after reenabling the correct (not working) code,
or to use the new VIDIOC ioctl's to enumberate the supported
formats.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The device name and the file descriptors are wrong at the cal for
v4l_check_yuv(). Due to that, the driver were falling back to work
with RGB formats.
While here, add a code to prevent V4L driver to work if no video
adapter provide Xv overlay method.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of providing an useless info that FBUF fails, print an
error indicating what's the Fourcc format that fails.
Also, on debug mode, prints a message indicating the selection of a
given fourcc. This helps to verify if both the video adapter and the
video capture board were set to the same video format.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix a small non-compliance issue: if a port attribute is not known,
according with Xv specs, it should return BadMatch, and not BadValue.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are several issues at GPA/SPA logic:
- driver tries to limit minimum/maximum values to -1000/1000;
- If yuv_format is available, all GPA/SPA are sent to the
overlay encoder at the video adapter;
- The most used return condition is an error.
Rework the entire logic to fix the above bugs and clean the
code.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
