| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| mfelsch | Hi together, I've question about the VIDIOC_TRY_FMT
What colorspace information should a driver return on the capture side upon this call? I asking because GStreamer added the colorimetry handling which now breaks a few pipelines on the imx6. | [08:20] |
| hverkuil | mfelsch: it depends on what sort of device it is: is this capture from a sensor? | [08:23] |
| mfelsch | The imx6 is returning the current set colorimetry information upon a try_fmt.
hverkuil: No it is a m2m device hverkuil: imx-media-csc-scaler.c | [08:23] |
| hverkuil | Ah. For an m2m device it copies the colorimetry data from the current output format (which is set by userspace).
In the open() function the driver has to fill in valid default colorimetry data for the initial output format. See e.g. vim2m.c. | [08:25] |
| mfelsch | "The imx6 is returning the current set colorimetry information upon a try_fmt" <-- and all gstreamer try_fmt() calls are ending in the same colospace information and gstreamer think it supports only this colorspace.. | [08:26] |
| hverkuil | It might be a gstreamer bug. | [08:27] |
| mfelsch | hverkuil: I see... Now I had a long discussion with a colleague of my about this situation | [08:28] |
| hverkuil | m2m devices really do not have colorimetry data as such, they just copy the colorimetry data that userspace sets as the output format to the capture format (exception would be a colorspace converter, but that's another story). | [08:28] |
| mfelsch | hverkuil: Yep, got that :)
hverkuil: But nothing is written in the doc.. | [08:28] |
| hverkuil | I think v4l2-compliance tests for this. Can you run the latest v4l2-compliance for that device?
I added tests for this, but that was probably after the imx scaler driver was merged. | [08:30] |
| mfelsch | hverkuil: During my internal discussion the question arises "why is this behaviour different for colorspace?" The size,byteperline,.. stuff can be differnet during try_fmt
hverkuil: v4l2-compliance from v4l2-utils 1.20? | [08:31] |
| hverkuil | The scaler doesn't change the colorspace. It's passed through from output to capture, just like e.g. the timestamp of a buffer.
No, from the git repo. | [08:32] |
| mfelsch | hverkuil: Okay, will try that. | [08:33] |
| hverkuil | What kernel version are you running? v4l2-compliance expects media_tree master (although it should be fine for mainline as well) | [08:33] |
| mfelsch | hverkuil: Yep, I know that the colorspace isn't changed but GStreamer uses the try_fmt to get all possible values on the capture and the output side.
hverkuil: 5.11 | [08:33] |
| hverkuil | 5.11 is probably OK. | [08:34] |
| mfelsch | hverkuil: Okay | [08:36] |
| hverkuil | that doesn't sound right what gstreamer does. It makes no sense to try all possible values for capture devices in general, unless one of the V4L2_FMT_FLAG_CSC_* flags is set for the capture format.
The colorimetry values on a capture device are normally fixed. The V4L2_FMT_FLAG_CSC_* flags are new and rarely set (they come into play if the hardware can do colorspace conversions as well) | [08:37] |
| mfelsch | hverkuil: My patch series will add the V4L2_FMT_FLAG_CSC_* flag handling. If this flag isn't the colorimetry information from the output is mirrored to the capture side
.. isn't set the colorimetry ... | [08:38] |
| hverkuil | I'm confused. Does gstreamer fail with the imx-media-csc-scaler.c as is currently in the kernel, or does it fail with your patch series adding V4L2_FMT_FLAG_CSC_* support? | [08:39] |
| mfelsch | hverkuil: My colleague is just wondering because a try_fmt should not limit colorspace information on the capture side | [08:40] |
| hverkuil | try_fmt(CAPTURE) depends on the current output format, that's always the case for m2m devices. So if V4L2_FMT_FLAG_CSC_* is not supported, then try_fmt(CAPTURE) will always return the colorimetry from the current output format.
Only if V4L2_FMT_FLAG_CSC_* is set can you try different colorimetry values. | [08:42] |
| mfelsch | hverkuil: Current GStreamer 1.18.x thniks that the imx-media-csc-scaler.c do only support one colorspace on its capture side. Reason is the try_fmt() implementation which returins 'only' the current set colorimetry. | [08:43] |
| hverkuil | But that sounds like a gstreamer bug. And possibly something that needs to be clarified in our m2m documentation. | [08:45] |
| mfelsch | hverkuil: Okay, got that thanks :) | [08:45] |
| hverkuil | ndufresne might know (a lot?) more about the gstreamer side. | [08:46] |
| mfelsch | hverkuil: Can we document that somewhere? So the user-space knows how try_fmt is handled.
ndufresne: ping :) | [08:46] |
| hverkuil | https://hverkuil.home.xs4all.nl/spec/userspace-api/v4l/pixfmt-v4l2.html#c.v4l2_pix_format already clearly states for the colorimetry fields that the driver sets this for capture in the absence of the CSC flags.
So trying different colorspaces for a capture device is pointless. It can be useful to write something in section 4.5 (Video Memory-To-Memory Interface) about how colorimetry information is handled. Patches are welcome. | [08:48] |
| mfelsch | hverkuil: Yep, I saw that but it says nothing about the fact that upon a try_fmt (which is used to parse the caps) it gets set to the current set val from the output side.
hverkuil: I will prepare some patches for the doc so user-space knows how to handle capability probing. | [08:56] |
| hverkuil | that would be nice. I don't disagree with you that this should be clarified, but that's about where the colorimetry information comes from in an m2m device, not whether you can try different colorimetry values with try_fmt on a capture device, since it is IMHO clear that that does not work (unless the CSC flags are set for the format). | [08:59] |
| dckusr | anyone here has expecriene using quallcom's venus encoder with v4l2 ?
also when sending a frame to encode with v4l2 must i fill the timestamp of the buffer ? | [09:02] |
| hverkuil | svarbanov: ^^^ | [09:05] |
| dckusr: the timestamp value is in most cases either ignored or copied from output to capture buffers in a memory-to-memory device. | [09:12] | |
| dckusr | but if i'm encoding from data I provide ? i.e. I generate the input video | [09:12] |
| hverkuil | just set it to 0, it's not used for anything. | [09:14] |
| dckusr | so... with my encoder if i set it to 0, and supply the frames not fast enough, it creates a hugh output video
if i supply the frames fast enough it's ok or if i set the timestamp, and not supply them fast enough, it's ok as ewll (ok = small video) so i guess this is encoder implmentation specific ? | [09:15] |
| hverkuil | Hmm, it looks like the venus driver does do something with the timestamps. You'll need to wait for svarbanov to pop up here. | [09:17] |
| dckusr | ohh, wow, cool, svarbanov is here, amazing | [09:18] |
| hverkuil | dckusr: this is what *should* happen with timestamp fields: see the first note in section 4.5.2.6 about timestamps:
https://hverkuil.home.xs4all.nl/spec/userspace-api/v4l/dev-encoder.html | [09:23] |
| dckusr | hverkuil: some codecs support for variable frame rate, how would they know how to set it, without the timestamp field ? | [09:27] |
| hverkuil | I don't believe we support that in any of the stateful encoder drivers at the moment, but I would expect that that would be done with VIDIOC_S_PARM for the OUTPUT queue.
Calling VIDIOC_S_PARM is one of the required initialization steps, but the spec doesn't mention if it can be changed later while encoding. | [09:32] |
| ........ (idle for 36mn) | ||
| svarbanov | dckusr, yes, you should fill timestamp on the input buffers. What version is Venus? | [10:10] |
| .... (idle for 16mn) | ||
| dckusr | i'm at home now, not near the hardware ... i can try asking
svarbanov: are IDR frames being put after each GOP size ? also is it documented anywhre that I need to put the timestamps in the input buffers ? | [10:26] |
| .... (idle for 15mn) | ||
| svarbanov: btw, if it's a constant frame rate: https://github.com/torvalds/linux/blob/master/drivers/media/platform/qcom/venus/venc.c#L559 why does the timestamp for the input matter ? | [10:42] | |
| ..... (idle for 20mn) | ||
| svarbanov | dckusr, I think the timestamp matter if rate-control is off. What RC mode you are setting | [11:02] |
| dckusr | CBR
also while i'm using an older kernel without this feature, where is there documentation of the effects of VFR/CFR here: https://github.com/torvalds/linux/blob/master/drivers/media/platform/qcom/venus/venc.c#L637 ? | [11:03] |
| .... (idle for 18mn) | ||
| svarbanov | dckusr, can you send an email to linux-media with all that questions and I'll try to respond there | [11:24] |
| hverkuil | svarbanov: I'd definitely like to know as well how the timestamp is being used in the venus driver. The V4L2 stateful encoder spec doesn't mention it at all.
Best to discuss this on the mailinglist. | [11:28] |
| ...... (idle for 25mn) | ||
| sailus | hverkuil: Can I take your IPU3 kernel-doc fix? I have some other patches for IPU3, it's unlikely to conflict though. | [11:53] |
| *** | jmondi_ has left | [12:00] |
| ....... (idle for 34mn) | ||
| hverkuil | sailus: sure, just delegate it to yourself in patchwork. | [12:34] |
| pinchartl | hverkuil: Ricardo has sent a set of fixes for uvcvideo to pass v4l2-compliance
a few of the patches add support for V4L2_CTRL_TYPE_CTRL_CLASS I wonder if we should really do that, or if that requirement should be dropped is V4L2_CTRL_TYPE_CTRL_CLASS really useful ? | [12:36] |
| hverkuil | pinchartl: yes, it is really useful for applications like qv4l2 since it allows it to group controls into tabs. All other drivers have it automatically through the control framework, so it is really nice if uvc would have it as well. | [12:38] |
| pinchartl | it's really something that should be hardcoded in userspace if you ask me :-)
I won't push back against the patches, it just seems unnecessary churn, but it's ok (same thing with control names or pixel format names btw, that shouldn't be part of the API in my opinion) | [12:41] |
| ..... (idle for 20mn) | ||
| *** | [LOGGER] has quit IRC (Ping timeout: 256 seconds) | [13:03] |
| ndufresne | mfelsch: there is indeed issues with colorimetry for m2m encoders, hverkuil might not have mention, but colorimetry support cannot be enumerated, and gstreamer would ideally need that information to ensure proper negotiation
the second issues is that v4l2 API is not 1:1 with how bitstream colorimetry is expressed, it focus on the function parameters, so all the BT2020 alias aren't expose, that often makes the colorimetry information not reversible, so even if a driver copied it properly, it might not come out the same All this colorimetry stuff isn't recent, it has 2-3 years already, it was mainly added to try and allow asking ISP for a specific colorimetry, but ended up having large side effect on m2m support mfelsch: I believe the long term solution is to stop negotiating that, and go with a best match approach (close by), and only warn when the match is bad for that, we have to implement a lot of logic in the plugin, which requires good understanding of colorimetry and what are the close match as usual, patches welcome, checkout master, there is already few fixes that made it, notably for IMX6 and I've sent them for backport into the next gst 1.18 release | [13:17] |
| mfelsch | ndufresne: My solution for a m2m transform element is to mirror the output colorimetry to the capture colorimetry
ndufresne: If the V4L2_FMT_FLAG_CSC_COLORSPACE flag isn't set | [13:25] |
| ndufresne | as I said, even if you mirror perfectly in the driver, doing GST to V4L2 to GST isn't perfectly reversible, in master someone added patch to simply remember what was set, so it can reverse | [13:26] |
| mfelsch | ndufresne: I will rebase my proposal onto master and will open a PR on gitlab so you can check what I mean | [13:26] |
| ndufresne | ok
it's specially needed for m2m transform, since when you do CSC conversion, you may change the colorimetry mfelsch: so you work with Micheal and Philipp ? | [13:26] |
| mfelsch | ndufresne: Yep, pH5 is a colleague and we've discussed this internally too | [13:29] |
| ndufresne | my only recommendation is that as soon as you fell your driver is doing the right thing, don't try and satisfy gst, since it might not be behaving perfectly well
mfelsch: the only reason it worked better in 1.14 and less, is because we were doing all possible calls to TRY_FMT, trying out every possible possibilities, performance was a disaster, we had cameras that would take up to 3 minutes to start | [13:30] |
| mfelsch | ndufresne: I've no problem with the v4l2src, my problems are on the m2m transform element
ndufresne: Because Gstreamer tries to probe the colorimetry on the capture side as well | [13:34] |
| ndufresne | it's all the same code, so whatever you change in one place, changes in the other place, except for v4l2src, which skips that completely
perhaps you want to mimic the caps negotiation from v4l2src into the decoder, not sure if the base class will let you do that (it does not have a fixate function) | [13:35] |
| mfelsch | ndufresne: Yep, I got this. | [13:36] |
| ndufresne | mfelsch: btw, it's worst with CODA, because it has some minimal CSC, which pH5 added code in gst for
though, I don' tthink it can change the colorimetry, it will scale up 4:2:0 to 4:2:2, but likely without scaling the colors If it does produce RGB, that's a different story | [13:38] |
| .... (idle for 15mn) | ||
| hverkuil | ribalda: my suggestion fixed the last compliance issue with uvc? It worked? | [13:54] |
| ribalda | hverkuil: actually it is more or less what I what I was using to test it. I could not easily update v4l2-utils in my target :)
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2749221/1/drivers/media/v4l2-core/v4l2-ioctl.c but I was not sure if it was a bug in the compliance test or in the kernel | [13:55] |
| hverkuil | ribalda: OK, good to hear. I never noticed this because I only tested v4l2-compliance with drivers that use the control framework. I haven't run it for uvc in ages (since it always failed :-) ), so I missed this problem in the core. | [13:57] |
| ribalda | hverkuil: maybe it will not fail anymore :P
I just sent a patchset for that | [13:58] |
| hverkuil | ribalda: I actually had similar patches in a branch: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=uvc-4.19 I just never got around to finish the work.
patch 1/10 can probably be dropped since V4L2_CTRL_WHICH_REQUEST_VAL will now be rejected in the core core. core code | [14:00] |
| ribalda | done ;) https://git.kernel.org/pub/scm/linux/kernel/git/ribalda/linux.git/log/?h=uvc-compliance-v2 | [14:03] |
| hverkuil | Regarding patch 3/10: why does this return an error at all? Is this due to buggy hardware? | [14:04] |
| ribalda | I think so
I have usb cameras that do not trigger that | [14:05] |
| hverkuil | I would like this to be clear from the commit log. Just to make it clear that this patch isn't just hiding real driver bugs, but just non-compliant FW/HW. | [14:06] |
| ribalda | ok, will fix in v2
most likely laurent makes me rewrite the whole thing :) | [14:08] |
| hverkuil | Did you test uvc with the 'full force' of v4l2-compliance? I.e.: v4l2-compliance -m /dev/media0 -s -f -a | [14:12] |
| ribalda | only v4l2-compliance -d /dev/video0 -T -v | [14:12] |
| *** | shibboleth has quit IRC (Ping timeout: 268 seconds) | [14:16] |
| ribalda | -s -f -a blocks
-f -a -> Failed:3 , Warnings: 9 | [14:16] |
| hverkuil | and just with -s?
It's really bad if -s by itself blocks. | [14:19] |
| ribalda | it blocks after test blockin wait: OK | [14:20] |
| mfelsch | ndufresne: MR is opened, so you can see what I mean :) | [14:20] |
| *** | NiksDev has quit IRC (Remote host closed the connection) | [14:23] |
| hverkuil | ribalda: ah, that's when you try to stream from the metadata device node and are *not* streaming from the video device node. v4l2-compliance doesn't know that streaming metadata only works if you are also streaming video. If you manually run 'v4l2-ctl --stream-mmap', then it should unblock. | [14:24] |
| ribalda | actually I have to run that, and then ctrl+c it
does it make sense? | [14:27] |
| hverkuil | ribalda: patch 08/10 looks like it is also no longer needed after the v4l2-ioctl.c fix. | [14:28] |
| ribalda | Always return a value on V4L2_CTRL_WHICH_DEF_VAL ? | [14:28] |
| hverkuil | I see I need to do ctrl-c as well. It's not obvious why that is. | [14:29] |
| ribalda | I think we still need the patch, otherwise if we have a miss-behaving control we get -ERROR instead of the default value
with the ctlr-c trick. Failed:10 | [14:30] |
| hverkuil | but why do you get an error from uvc_query_v4l2_ctrl in the first place?
if it is an unknown control, then you want to return an error. I think something else is going on here. | [14:32] |
| ribalda | my camera has a duplicated entity name :) | [14:37] |
| *** | kaspter has quit IRC (Remote host closed the connection) | [14:37] |
| ribalda | fail: v4l2-test-media.cpp(205): v2_entity_names_set.find(key) != v2_entity_names_set.end() | [14:38] |
| hverkuil | what camera do you have? My HD Pro Webcam C920 has hte same issue.
Ah, this is probably the driver that does this: I suspect it uses the same name when creating the entities for the video nodes. | [14:39] |
| ndufresne | mfelsch: commented on the patchset, the approach looks good, but I pretty sure that change in the kernel API was not really backward compatible with let say Samsung MFC driver, cc hverkuil
which I think the solution would be to port that driver to use this flag, and make sure colorimetry is done right, RGA is pretty similar perhaps mchehab still have access to that HW ? there was one on Exynos 4 and another on Exynos 5 we should also perhaps have a mode in vim2m, so it can run with and without that flag for testing purpose | [14:45] |
| mchehab | ndufresne: I don't have access to it anymore. I would try contacting Sylwester | [14:49] |
| dckusr | hverkuil: how is v4l2-compliance testing the timestamp thingy ? | [14:51] |
| hverkuil | ndufresne: I think I have an exynos4 odroid. But it is almost certainly in the Netherlands, and it will probably be a few more months before I can travel.
dckusr: I suspect it doesn't test it for a stateful encoder. What timestamps the encoder produces on the capture side is rather HW/SW dependent, so there isn't anything specific to test. | [14:52] |
| *** | newbieAlert has quit IRC (Quit: newbieAlert) | [14:59] |
| ndufresne | hverkuil: mchehab: ok, thanks, I really need CI for this, so that this type of boards can be hooked in kernelci, and tested there ...
it's really a pain, since when folks like mfelsch bring gst fixes, I never know how well these fixes works across all boards, since these fixes always comes with their respective driver using a new API | [15:08] |
| *** | taliho has quit IRC (Quit: The Lounge - https://thelounge.chat) | [15:15] |
| ribalda | hverkuil: I am trying with a very very very very miss-behaving endoscope
and with a Xiaomi notebook | [15:18] |
| hverkuil: now it passes -s -f -a for /dev/video0
https://git.kernel.org/pub/scm/linux/kernel/git/ribalda/linux.git/log/?h=uvc-compliance-v2 there are two more patches an a reorder I still need to figure out how to pass -M /dev/media0 | [15:28] | |
| hverkuil | ribalda: re "media: uvcvideo: Return 0 on streamon": first of all, the subject should be streamoff, not streamon. Secondly, I don't think this is right: if one filehandle is streaming, then another filehandle cannot call streamoff and should see EBUSY as error.
The problem is that the whole 'privileges' scheme in uvc is different from what all other drivers use. I think I tried at one time to move uvc to the standard vb2 helper functions which take care of much of that: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=uvc-4.19&id=a6a0a05f643521d29a4c1e551b0be73ce66b7108 I ran out of time I think, so it was abandoned, but it would simplify things a lot if uvc would switch to using the vb2 helpers. Those helpers didn't exist when uvc was written, but today they make life a lot easier. | [15:40] |
| ribalda | hverkuil: I think in this case the issue is that another file handle has done the buffers precurement
and then we call streamon (the subject is of course wrong, I need to fix that) when a fh calls s_fmt, reqbufs, create_bufs, s_input or s_param it gets "privileges" sergey has worked much more with vb2 I will try to convince him to continue with your patch | [15:56] |
| hverkuil | This test: "fail: v4l2-test-buffers.cpp(1265): node->streamon(q.g_type()) != EINVAL" checks that streamon returns EINVAL if no buffers are allocated. But your 'fix' does not test for that, instead it just changes the return code from EBUSY to EINVAL, which will now mean that if a second file handle tries to call streamon while the first filehandle is already streaming, it will now return EINVAL instead of EBUSY.
The whole privileges concept is basically legacy code from the olden days when the v4l2 core frameworks sucked. | [16:04] |
| ribalda | :) | [16:06] |
| hverkuil | But is now ever so slightly out of sync with how things work today. | [16:06] |
| ribalda | what about, if vb2_is_streaming() -> -E_BUSY, EINVAL otherwise? | [16:06] |
| pinchartl | ribalda: you were right, I've asked you to change the approach ;-)
(see patch 06/10) I think the implementation can be simplified quite a lot | [16:07] |
| *** | dckusr has left | [16:07] |
| pinchartl | hverkuil: regarding the privileges system, I'd be happy to move to standard helpers | [16:08] |
| hverkuil | ribalda: I would try to continue work on replacing this legacy code with using the vb2 helpers. My patch (probably incomplete) reduces the code by almost 400 lines. Trying to keep hacking the privileges hack in uvc will just be painful. | [16:08] |
| One thing that is missing in my patch is that the lock field of struct vb2_queue should point to &stream->mutex. All streaming ioctls in uvc already take this lock, but when moving to the vb2 ioctl helpers the vb2_queue lock field must point to it since now the v4l2 core will take that lock.
the patch doesn't apply anymore either, I think it predates metadata support in uvc. | [16:16] | |
| ribalda | pinchartl: does libcamera uses /dev/media for uvc?
or maybe better, who is using video1 and /dev/media for uvc? hverkuil: I think you are right I will leave the streaming part | [16:17] |
| pinchartl | ribalda: libcamera uses the MC API for everything
it's the only way to enumerate devices in libcamera | [16:18] |
| hverkuil | ribalda: from what I remember that branch in my git repo was work-in-progress. I think it compiled, but it wasn't actually checked for correctness yet. | [16:19] |
| pinchartl | ribalda: why ? | [16:20] |
| ribalda | pinchartl: because now I am trying to fix -M, and I want to test that I havent broken it
passing v42l-compliance is good. Getting images is even better :) | [16:20] |
| pinchartl | run qcam with a uvcvideo device
series reviewed | [16:22] |
| *** | rcoote has quit IRC (Ping timeout: 256 seconds) | [16:24] |
| ribalda | thanks! | [16:24] |
| hverkuil | I now remember why I never continued with fixing all the compliance issues with uvc: It was a lot of work :-) | [16:28] |
| pinchartl | :-) | [16:36] |
| ribalda | hverkuil: :) , but we are getting there
my patchset + an updated version of your vb2 patch (+ whatever is needed for -M ) | [16:37] |
| ...... (idle for 25mn) | ||
| *** | sszy has quit IRC (Ping timeout: 260 seconds) | [17:03] |
| frispete__ has quit IRC (Ping timeout: 264 seconds) | [17:17] | |
| GBenji has quit IRC (Quit: Leaving.) | [17:25] | |
| ...... (idle for 27mn) | ||
| svarbanov has quit IRC (Ping timeout: 246 seconds) | [17:52] | |
| .... (idle for 15mn) | ||
| prabhakarlad has quit IRC (Quit: Connection closed) | [18:07] | |
| robertfoss | hverkuil: the camss sdm845 series is ready for merging now.
hverkuil: thanks for pinging me the other day | [18:12] |
| .......... (idle for 49mn) | ||
| hverkuil | robertfoss: can you run 'scripts/checkpatch.pl --strict' over the patches? I see a fair number of warnings there, most look trivial. | [19:02] |
| robertfoss | ack | [19:02] |
| hverkuil | Let me run a quick compile build as well to see if there are any other issues. | [19:03] |
| robertfoss | with --strict I'm seeing issues with 10-17, let me go through those and send out v8 | [19:06] |
| hverkuil | just wait a bit, I'm compiling the series now, see what I get.
quite a few sparses/smatch warnings. I'll reply to the cover letter. | [19:06] |
| robertfoss | thanks! | [19:11] |
| hverkuil | replied to cover letter. | [19:12] |
| *** | jmondi1 has left
mszyprow has quit IRC (Ping timeout: 260 seconds) | [19:22] |
| ..... (idle for 23mn) | ||
| mani_s has quit IRC (Ping timeout: 265 seconds) | [19:47] | |
| .... (idle for 18mn) | ||
| Robert_Zenz has quit IRC (Quit: Robert_Zenz) | [20:05] | |
| ........... (idle for 53mn) | ||
| APic has quit IRC (Ping timeout: 240 seconds) | [20:58] | |
| ...... (idle for 26mn) | ||
| ao2 has quit IRC (Quit: Leaving) | [21:24] | |
| .................. (idle for 1h27mn) | ||
| danvet has quit IRC (Ping timeout: 272 seconds) | [22:51] | |
| .... (idle for 16mn) | ||
| pinchartl has quit IRC (Ping timeout: 260 seconds) | [23:07] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |