hello, i get this error: ERROR    dvb_read_section: read error: Value too large for defined data type    when i use libdvbv5 to do dvb things ? how to fix it ?
hello
xxx_: it means not reading fast enough and/or using a too small buffer size
i'm getting that too and don't know what's wrong though
I found what was wrong, and I was not reading fast enough
hverkuil: I have a new series of 40 patches addressing y2038/time_t issues, and mostly removing 'struct timeval' from the kernel.  v4l2_event and v4l2_buffer still remain so far. Has there been any progress with those structures on your side?
For reference, this is where we were two years ago: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg46631.html
arnd: it's not forgotten. The problem is that there are two other projects running that touch on the same buffer structures (vb2 fence support and the Request API) and there is no point continuing with this until those two are mainlined.
hverkuil: any idea how long that might take?
I sincerely hope it will be in before 2038 :-)
my hope was to eliminate 'struct timeval' by 4.17, with most users gone by 4.16
The vb2 fence work is progressing nicely and I hope that that will be merged this year.
and that's the one touching v4l2_buffer, right?
The Request API (and that's also what might well impact my y2038 patch series) is something we hope to get in Q1 next year or Q2 is we're unlucky.
yes, both touch on it.
ok
The request API has been the blocker all that time and it is been very painful, but we came to an agreement on how to move forward last month during the ELCE.
We also have Google working on this, so I hope we will finally make progress there.
There is also a chance that the Request API work will actually require my patch series to be moved forward. It all depends on the details.
I could perhaps do a much simpler version of my patch and replace the 'timeval' in there with a structure that is always using '__kernel_long_t' for the seconds, and thus not needing two different versions. That should not conflict with any other rework, but it has a risk of breaking user applications at compile time when they assume that v4l2_buffer-> timestamp can be accessed using a 'struct timeval' pointer
not sure if that would be an option then
See my patch series here: https://www.mail-archive.com/linux-media@vger.kernel.org/msg121215.html
The first can probably be merged earlier since it doesn't touch v4l2_buffer.
Sorry, I meant the second patch (DQEVENT).
arnd: it wouldn't hurt if you could take a quick look at these two from a y2038 point of view.
hverkuil: thanks for the link. The first patch seems fine, it introduces a sane interface and no new y2038 problem
the second patch doesn't look right though
What's the patch? VIDIOC_DQEVENT?
Sorry
What's the first patch? VIDIOC_DQEVENT?
first patch (good): [RFC PATCH 1/2] v4l2: add extended streaming operations, https://www.mail-archive.com/linux-media@vger.kernel.org/msg121217.html
second patch (not good) [RFC PATCH 2/2] v4l2-core: make VIDIOC_DQEVENT y2038 proof. https://www.mail-archive.com/linux-media@vger.kernel.org/msg121216.html
What's the issue with patch 2/2?
adding the timestamp64 member doesn't help here. The data in the existing timestamp field is already y2038-safe
the problem it fails to solve is the incompatible structure layout
Hmm, I need to refresh my memory.
when glibc redefines 'struct timeval' to be 'long long tv_sec; long tv_usec', it will be larger than the existing structure and all fields are in the wrong location
well, the 'id' field and the 'timestamp' at least. In other subsystems I think you would also copy too much data, but that is handled correctly in v4l2 iirc
hverkuil: back in https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg46633.html, you suggested this should be handled in video_usercopy()
yeah, I'm reading that mail thread as well.
So glibc will redefine both struct timeval and struct timespec, right?
right
the new definition is quite tricky in fact, since  tv_nsec must be 'long' according to C99, and but we also want the layout to be the same between 32-bit and 64-bit architectures, so we need extra padding in the right place, which in turn is different between big-endian and little-endian
Was that change only for 32 bit architectures or also for 64 bit? Or do 64 bit arches already use s64?
64-bit architectures don't change, they already use 'long' for both tv_sec and tv_nsec/tv_usec
(sorry for asking this, it's been so long since I looked at this)
no worries
you mean 'long long' for tv_sec?
no, right now everyone uses 'long tv_sec', and that is 64-bit wide on 64-bit architectures
Ah, of course. Sorry.
Let me dig into this a bit more tomorrow morning. The v4l2_buffer changes will have to wait (sorry), but it would be nice if VIDIOC_DQEVENT can be fixed.
hverkuil: I just tried to implement your suggestion, but haven't tried compiling it yet, see https://pastebin.com/jjwivwzk
this is for VIDIOC_DQEVENT
ignore the changes to drivers/media/v4l2-core/v4l2-ioctl.c there
To be continued tomorrow.