| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | gnurou has quit IRC (*.net *.split)
grohne has quit IRC (*.net *.split) | [01:00] |
| .......................................................................................... (idle for 7h28mn) | ||
| grohne | I've been talking about upstreaming an media/i2c driver recently and said I'd defer the "bridge driver". that turned out to be useful, because it left me working on the i2c driver, but now I need bridge functionality. can someone point me at an example bridge driver to look at? I don't quite know where to look | [08:28] |
| hverkuil | grohne: depends on your device: is it PCI? USB? A platform device? | [08:29] |
| grohne | hverkuil: it's an aptina/onsemi imager configured via i2c. the video data presently leaves linux' knowledge into an external processor.
so I wont get a video device capable of capturing any time soon, but I'd like to get a bit more of a video device that a /dev/v4l-subdev0 just enough so I can continue working on the i2c driver and submitting it to mainline eventually | [08:30] |
| hverkuil | bridge drivers are all about capturing video, so without that capability there is not much point in attempting to make such a driver.
(unless I misunderstand you) Is it possible to hook the sensor up to some SBC? Then you can use the platform bridge driver of that system. | [08:34] |
| grohne | the sensor is hooked up to some sbc, yes.
so what I think I need is some driver that creates a /dev/video0 such that I can use media-ctl and v4l2-ctl and perhaps most importantly v4l2-compliance that driver doesn't have to be pretty, nor go to mainline, it just needs to provide enough glue to use standard testing tools | [08:37] |
| hverkuil | but I gather that your sbc doesn't have video capture capabilities? (I.e. a DMA engine able to capture video)
v4l2-compliance can test v4l-subdev devices these days, BTW. | [08:39] |
| grohne | it kinda does. but the sbc doesn't get the video data from the image sensor, it rather gets quite different video data from a co-processor via dma (not using v4l in any way at present) | [08:40] |
| hverkuil | Most of the v4l2-compliance tests for video devices test the bridge driver, not the subdev device, so it does not really help you if the goal is to verify your i2c drivers. Running v4l2-compliance on the v4l-subdev device is sufficient for that. | [08:41] |
| grohne | looks like v4l-utils in debian stretch is too old for that. | [08:41] |
| hverkuil | always compile straight from the v4l-utils repo | [08:42] |
| grohne | in defense, apt-get install was easier ;) | [08:42] |
| hverkuil | distros always have old versions, esp. for the compliance tests. | [08:42] |
| grohne | does it make sense to try to support the media controller framework in the i2c driver whan that is the first driver converted to v4l?
btw. the reduction in redundnat code while converting from crazy ioctls to v4l was fairly impressive :) | [08:45] |
| hverkuil | grohne: I would recommend adding MC support. It will be needed if it is going to be used with MC bridge drivers. And it is not a lot of code to add support for it in a subdev driver. | [08:47] |
| grohne | it's not a lot of code at all, but code I cannot seem to test in any way | [08:48] |
| hverkuil | No, not without an MC bridge driver. But we can review that code easily.
I wonder if it would be useful to have a subdev test bridge driver for situations like this. But I have zero time to work on something like that. | [08:49] |
| grohne | not sure whether it makes sense to send the current state for kinda pre-review. there are still a number of sharp corners, but it seems roughly in shape now.
likely I still got a lot of things wrong, so I don't expect much code to stay like it is though. | [08:51] |
| hverkuil | We don't mind getting rough code, just make sure it is marked with RFC and mention in the cover letter what the status of the driver is, so we're not trying to do a full code review. | [08:52] |
| grohne | I'll keep that in mind. thank you.
I would certaily have added RFC anyway. | [08:53] |
| hmm. even v4l-utils 1.14.2 is too old for subdev stuff it seems
that still leaves my initial question of what example driver to lookkkkkkkkk at | [09:05] | |
| hverkuil | drivers/media/platform/atmel/atmel-isi.c is a simple one. Also samples/v4l/v4l2-pci-skeleton.c can be helpful, although that's a pci skeleton driver.
To build v4l-utils: git clone https://git.linuxtv.org/v4l-utils.git/ cd v4l-utils ./bootstrap.sh ./configure make sudo make install | [09:17] |
| ribalda | @sailus Hello! I am working on an upstreameable vesion of an ims214 driver. The last thing left is splitting the sensor module and the focus module. I am trying to use "lens-focus" async sub-device . Everyhing seems fine, but the power management
because the focus device is not part of the pipeline the s_power function is not called | [09:25] |
| hverkuil | ANN: I'll start preparing the agenda for the upcoming Media Summit in Edinburgh on Monday, so if you want to discuss/present something on that day, please send an [RFP] mail to the linux-media mailinglist asap.
ribalda: ims214 or imx214? | [09:26] |
| ribalda | imx214
hverkuil: everything works fine on my db820 board, but the focus is controlled by the same driver, and it shoudld be controlled with the ad5820 driver | [09:26] |
| hverkuil | I thought we were using the same sensor, but it is a different one. Just ignore me :-) | [09:29] |
| ribalda | hverkuil: sorry, I have fat fingers :P | [09:29] |
| tfiga | ribalda: wouldn't you normally have the userspace keep the focuser subdev open and control the focus continuously?
the focuser drivers we've been implementing power on on subdev open | [09:33] |
| ribalda | tfiga: then what is the point for referencing the focuser on the sensor on the device tree? | [09:36] |
| tfiga | ribalda: to know which focuser belongs to which sensor I guess
although I'm not saying that behavior is the officially blessed one ;) I don't think it's specified anywhere... | [09:40] |
| ribalda | tfiga: but I think that information is not accesible, at least is not shown in media-ctl -p | [09:47] |
| hverkuil | ribalda: this is information that should be represented through properties, but we still don't have those in the MC. We're working on it, though.
I hope I can resume my work on properties next week. | [09:58] |
| grohne | hverkuil: thank you. I'll read up on the atmel-isi driver. I already recognize some bits from my dummy bridge. | [10:04] |
| ............................................. (idle for 3h40mn) | ||
| ezequielg | hverkuil: regarding
media: usb: pwc: Don't use coherent DMA buffers for ISO transfer i think it's good to go. | [13:44] |
| hverkuil | ezequielg: I would like to see an Ack from pinchartl or someone else with USB experience. I'm not the best person to review this. | [13:48] |
| ezequielg | hverkuil: ok, let's see if Alan or Laurent can ack or nack this. | [14:00] |
| hverkuil | ezequielg: thanks. Sorry, this is not my area of expertise. | [14:02] |
| pinchartl | hverkuil: "[PATCH v3 1/2] media: v4l2-subdev.h: allow V4L2_FRMIVAL_TYPE_CONTINUOUS & _STEPWISE" reviewed
you might not like the answer though but I think it's time to correct the mistake we made | [14:11] |
| .... (idle for 16mn) | ||
| hverkuil | pinchartl: I think I agree with you for the most part. And this is an excellent topic for the media summit. I'll post an RFP. | [14:28] |
| pinchartl | hverkuil: \o/ | [14:29] |
| grohne | hverkuil: your pointing at atmel-isi was very helpful | [14:39] |
| ezequielg | pinchartl: Alan throwed the ball to your court. Any chance we don't keep stalling this? any feedback is better than no feedback. | [14:46] |
| ................... (idle for 1h32mn) | ||
| *** | benjiG has left | [16:18] |
| ..... (idle for 21mn) | ||
| ezequielg | mripard: paulk-leonov: can you point me at latest development for cedrus?
i'm working off br-cedrus tag from Hans tree. not sure if i need more patches. i don't care about the checkpatch crap, btw. | [16:39] |
| hverkuil1 | ezequielg: if there is anything newer, then it hasn't been posted to linux-media.
So my tree is still the latest AFAIK. | [16:40] |
| ezequielg | then i'm fixing some bugs i think.... | [16:42] |
| pinchartl | ezequielg: I'll review the patch | [16:42] |
| .......................... (idle for 2h5mn) | ||
| ezequielg | mripard: paulk-leonov : after picking up the drm pieces, i managed to test the mpeg decoding :-) | [18:47] |
| paulk-leonov | ezequielg, nice! | [18:47] |
| ezequielg | what's the blocker on gst-vaapi? | [18:48] |
| paulk-leonov | ezequielg, it's broken it various ways for our use case
I couldn't get kmssink to use the v4l2 memory pool via dma-buf it seems that both are creating their own buffers | [18:48] |
| ezequielg | kmssink is not gst-vaapi :-) | [18:49] |
| paulk-leonov | right fair enough
gl won't work because of the blobs but IIRC I coudl get one frame decoded with ximagesink | [18:49] |
| ezequielg | i know about the kmssink stuff, not exactly sure what's going on but it's on my radar. | [18:49] |
| paulk-leonov | which is not dma-buf | [18:50] |
| ezequielg | ok | [18:50] |
| paulk-leonov | the test setup for vaapi is mostly vlc with XCB for now | [18:50] |
| ezequielg | so, let me see if i follow, there is no issues with gst-vaapi per-se.
just issues rendering the decoded buffers afterwards. i mean my question is: filesrc ! vaapidec ! fakesink - does it work? | [18:51] |
| .... (idle for 17mn) | ||
| paulk-leonov | I haven't tried it, but seems like a good way to start | [19:09] |
| ezequielg | yeah, fakesink is your friend. or fakevideosink. | [19:11] |
| ........... (idle for 50mn) | ||
| ndufresne | paulk-leonov, right now, if you support non-dmabuf frames, kmssink will copy into dumb buffer, so you still should see something on screen, but slow
do you see anything? I can explain you the story, I even got (kindly) angry about the state of gstreamer-vaapi, because it has never been ported to the new VA API that fixes the disaster of the first DRM API so we decided not to go forward with enabling dmabuf caps feature between the two paulk-leonov, on intel driver, the dmabuf secretly have modifiers, which renders like shit on kmssink, the gpu driver have some ancient code to find back from the memory pointer the modifiers to use | [20:01] |
| paulk-leonov | ah yes indeed I also had to add the caps, but still didn't work -- looks like buffer copy still did not happen | [20:03] |
| ndufresne | well, of course, kmssink would need to work at all ;-D | [20:04] |
| paulk-leonov | ok, so that confirms my impression that this pipeline was not supported in gstreamer-vaapi | [20:04] |
| ndufresne | have you tried with vaapisink ?
oh wait, that only works on X11/Wayland sorry paulk-leonov, any cheap board supported, I should start getting equipped I guess if I ever want to get this to progress | [20:04] |
| ..... (idle for 23mn) | ||
| paulk-leonov | ndufresne, yeah there are a bunch of cheap H3 boards with HDMI
http://linux-sunxi.org/Category:H3_Boards H3 is the only setup we currently support that has H265 btw | [20:29] |
| ndufresne | ok | [20:33] |
| ..... (idle for 21mn) | ||
| ribalda | Sorry for the spam :(. | [20:54] |
| pinchartl | ribalda: :-) | [20:54] |
| ribalda | btw is anyone comming to the kernel-recipes, embedded-recipes? | [20:54] |
| pinchartl | I'll be in Spain for XDC I'm afraid | [21:01] |
| ribalda | @pinchartl Ahh, yes, at Igalia. It is a pity that both confereces overlap | [21:04] |
| ................ (idle for 1h17mn) | ||
| *** | jmondi has quit IRC (Ping timeout: 252 seconds) | [22:21] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |