07:13MrCooper: mlankhorst: does "[PULL] drm-misc-next" really need to be 1.25 MB?
09:43mlankhorst: hm no, wonder why it is
09:47MrCooper: meson-scons job broken for the first time, let's see for how long :)
12:43pcercuei: sravn: I think mipi_dbi_spi1_transfer() has never ever worked
12:45pcercuei: it converts (chunk) bytes to (chunk) 16-bit words, and then does a SPI transfer of (chunk) bytes from that 16-bit buffer
12:45pcercuei: So only half the data is transfered
12:47udovdh: what happened here? https://paste.centos.org/view/b8b4b030
12:47udovdh: it occurs after I start mpv to play a timelapse video
12:48pcercuei: usually I'd send a fix, but it's been 3 years and nobody noticed, so I guess it's basically dead code
12:48karolherbst: kusma: will nuking the tegra driver in favour of kmsro cause any issues for grate? no idea how active the development there are but you seem to be involved
12:48udovdh: 4000x3000 H.264 video. used to play ok, now crashes the gui part quite well.
12:49udovdh: is this a mesa issue or problem in xf86-video-amdgpu ?
13:24udovdh: We see: [gfxhub0] retry page fault (src_id:0 ring:0 vmid:1 pasid:32779, for process mpv pid 13063 thread mpv:cs0 pid 13074)
13:24udovdh: and then it retries and retries
13:24udovdh: then we see [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered
13:24udovdh: but hte gui stops responding
13:25udovdh: In mpv we use:
13:25sravn: pcercuei: reading the code it looks like each byte is copied to a 16bit entry, and then the transfer is set up to 9 bits. So from my quick glance the code looks ok
13:26sravn: Di you see something that indicated that what was sent over SPI was wrong?
13:26pcercuei: sravn: you expand X bytes into (X*2) bytes, then transfer X bytes
13:27pcercuei: yes, it did not work with my panel until I added a *2 there
13:27LiquidAcid: udovdh, vdpau with vaapi?
13:27LiquidAcid: doesn't look sane to me
13:27sravn: but tr.len should be the number of 16bit entries?
13:28udovdh: works for any video I download
13:28udovdh: but we can try something else
13:28sravn: Anyway, drop a patch and lets see what Noralf says, he wrote this code and knows it way better then me
13:28udovdh: if I recall hwdec=vdpau gave me a message about soemthign being sub optimal
13:28udovdh: or somethign like that
13:29pcercuei: sravn: no, tr.len is the transfer length in *bytes*
13:31sravn: pcercuei: see it now "len: size of rx and tx buffers (in bytes)" - from spi.h
13:31sravn: So code has been broken for anything that transfers more than a single byte..
13:32udovdh: hwdec=vdpau gives the same result
13:35LiquidAcid: udovdh, why don't you just use hwdec=auto?
13:35udovdh: will that work better?
13:35LiquidAcid: afaik amdgpu doesn't even have native vdpau
13:36udovdh: and what do we sue for vo in such case?
13:37LiquidAcid: i don't even set vo in my config
13:37LiquidAcid: should default to gpu afaik
13:42udovdh: hwdec=auto did not change behaviour
13:49udovdh: so the issue is simple and can be reproduced.
13:49udovdh: make a timelapse video using a photo camera at 4000x3000
13:49udovdh: play that video on this hardware with fedora 31 and git mesa
13:49udovdh: and boom
13:50udovdh: video is h.264, 25 frames per second, 92433 kbps, 4:2:2 profile
13:55tango_: ehm sorry
14:13udovdh: do I file a bug? against what component?
14:14karolherbst: udovdh: against mesa and upload the video.. but you might want to try to reduce the size a little
14:15udovdh: I do not want to reduce the size as I will lose resolution or surface area
14:15karolherbst: udovdh: I meant for the bug report
14:15karolherbst: such videos can explode in size quickly
14:16udovdh: under 1 GB
14:16udovdh: but perhaps a few seconds are enough to trigger the issue?
14:16udovdh: dunno yet
14:16udovdh: I will try to find out and file a bug later
14:16karolherbst: yeah.. I just expect that we have some upload limit :) you can try, but I wouldn't be surprised if you run into problems
14:29MrCooper: LiquidAcid: radeonsi does have native VDPAU (& VA-API) support
14:46LiquidAcid: MrCooper, i always thought vdpau was more like a nvidia thing
14:46MrCooper: the API was created by Nvidia, just the VA-API one was by Intel
14:47MrCooper: just as
14:51emersion: we need a third one!
15:03mripard: OpenMax IL ? :)
15:11daniels: karolherbst: kusma is on holiday this week, so you might want to ask again in a few days
15:44karolherbst: I just hope we get the video/audio quality right, thinking about a potential talk to give, but I don't have any proper equipment here
16:09daniels: karolherbst: the Logitech C920 HD is pretty much ubiquitous as a webcam and has really nice quality; I also have the Fifine K670 as a microphone to record talks but that's arguably overkill - if you have headphones with an inline mic, those generally work well enough once you get the gain right
16:11imirkin: i think the key is to test it out yourself first, which gives you the opportunity to make any tweaks
16:12imirkin: you can make almost any equipment work reasonably well
16:21emersion: so, i have this analog camera…
16:22imirkin: don't worry - i got you covered. see how i said "almost"? :)
16:23imirkin: i try to leave myself an out for such occurrences :p
16:37karolherbst: daniels: well... "quality"
16:38karolherbst: ohh.. actually I have a proper camera but no idea if I can get rid of the HUD shit :D
16:39karolherbst: but there is also more to it
16:39karolherbst: like the slides also need to be in the feed, etc...
18:35pcercuei: I would like to specify that if my two planes are disabled, then the hardware won't generate a VBLANK interrupt
18:35pcercuei: So I set "crtc_state->no_vblank = true" in my CRTC's atomic_check() callback
18:35imirkin: karolherbst: you can look into using OBS Studio to put out a stream with camera + other things in it
18:36pcercuei: But it does not seem to work... drm_atomic_helper_wait_for_vblanks() throws me a warning, that "vblank wait timed out"
18:36imirkin: i believe that's what the kids are using on twitch and such
19:00karolherbst: imirkin: right... but it's not as simple as that ;) you also need somebody to manage the streams and stuff
19:00karolherbst: we don't want to hop streams for every new talk etc... ;)
19:00karolherbst: but there are already solutions for that out there somewhere
19:01karolherbst:already attended a virtual conference where the people knew what they were doing
19:01imirkin: karolherbst: i mean if you want to publish a composite image of you + various content
19:01karolherbst: imirkin: also you need to handle connection loss and stuff
19:01imirkin: sure. but that's no different than if you just had a camera
19:02karolherbst: and display the xorg logo or the "introducer to the talk" takes over etc...
19:02karolherbst: sure, you can just display nothingness and let everybody connect to the stream
19:02karolherbst: or you do it properly :p
19:02imirkin: right. to the xdc organizer needs stuff. but as a producer of a talk, you can just publish a full-frame image that's a composite of whatever you want. that was my only point.
19:02karolherbst: ahh, yeah
19:02imirkin: (and that there are tools to let you do that)
19:03karolherbst: yeah.. I guess mixing the recording and recording the desktop is a solved issue indeed
19:03imirkin: and then if the xdc organizers want to slap the xorg logo in the middle of your face, that's their call :)
19:05karolherbst: ohh. I meant more between the talks and stuff :p
19:06imirkin: right. my point is that you send the stream to them, and then they send it on
19:06imirkin: so that they can handle any mixing they want to do
19:06karolherbst: my upload is just crappy.. sadly :/
19:07karolherbst: so no high quality stream from me anyway
19:07imirkin: yeah, not sure that can be fixed easily :p
19:07karolherbst: I could increase it I think...
19:07imirkin: maybe there's a turbo button on your modem? :)
19:07karolherbst: but not quite sure if 30 mbit is that much better than 20 mbit :p
19:07imirkin: it's at least 10mbit better...
19:08karolherbst: and double as expensive
19:08karolherbst:just wants to have real fibre
19:28pcercuei: Is it possible to commit *something* before a VBLANK?
19:29pcercuei: My HW has a shadow register for the framebuffer DMA address. But when I get the VBLANK interrupt, it's already too late to write the new address :(
19:29pcercuei: So I'd need to write the new address to the shadow register, then wait until the next VBLANK. I'm not really sure how to do that
19:38sravn: Hi narmstrong, any chance you could take a look at "drm/bridge: support chained bridges + panel updates". Just posted to dri-devel in v3
19:40narmstrong: sravn: hi, let me have a look
19:40sravn: pinchartl: Your critical eyes on "drm/bridge: support chained bridges + panel updates" would also be appreciated
19:40sravn: narmstrong: Thnaks!
19:43pinchartl: sravn: I'll have a look
19:49sravn: pinchartl: Thanks to you too!
19:50narmstrong: sravn: it looks fine for me, but pinchartl may have some useful comments to add
22:36dinosomething: can anyone point me to documentation about xorg's loading of config files? preferably things like, the order in which configs are loaded, and what takes precedence etc when multiple sections are similar?