[00:36] *** tnt_ changes his alias to Guest71832
[13:41] <shuah> hverkuil, larsc: took some work looking through lots of code, finally I have a handle on major and minor for snd-usb-audio
[13:43] <mchehab> shuah: there are some problems with major/minor on ALSA
[13:44] <shuah> no problem with major and minor
[13:44] <mchehab> ?
[13:44] <shuah> I just had to figure out where to find it
[13:44] <mchehab> what alsa devnode are you mapping?
[13:44] <mchehab> crw-rw----+ 1 root audio 116, 2 Jul 1 09:57 /dev/snd/controlC0
[13:44] <mchehab> crw-rw----+ 1 root audio 116, 4 Jul 1 09:57 /dev/snd/pcmC0D0c
[13:44] <mchehab> crw-rw----+ 1 root audio 116, 3 Jul 1 09:57 /dev/snd/pcmC0D0p
[13:45] <mchehab> crw-rw----+ 1 root audio 116, 1 Jun 28 19:54 /dev/snd/seq
[13:45] <mchehab> crw-rw----+ 1 root audio 116, 33 Jun 28 19:54 /dev/snd/timer
[13:45] <shuah> I am linking pcm dev to tuner
[13:45] <mchehab> all those are alsa devnodes for just one device
[13:45] <shuah> CAPTURE dev
[13:47] <mchehab> media controller doesn't support 'alsa capure dev'
[13:47] <mchehab> it supports something undefined
[13:49] <mchehab> the first thing we need to do is to define exactly the ALSA entities that will be supported
[13:49] <mchehab> then we need to patch media-ctl to understand them
[13:50] <shuah> right I agree
[13:50] <mchehab> otherwise it will display "null"
[13:50] <mchehab> for the devnode
[13:51] <shuah> exactly - that is what I am seeing now.
[13:51] <mchehab> here, au0828 is creating two new alsa devices: controlC2 / pcmC2D0c
[13:52] <shuah> I am also seeing an error from dvb when it tries to setup link - I have to debug that as well. This is on the latest linux_media media-controller branch
[13:52] <mchehab> both likely need to be represented via the media controller
[13:52] <mchehab> I think control is used by the mixer, but not 100% sure
[13:53] <mchehab> pcmC is the capture devnode
[13:53] <shuah> correct
[13:56] <shuah> mchehab: in struct media_entity_desc there are a couple of ifdefed out place holder fields for alsa and v4l
[13:56] <shuah> and fb
[13:56] <shuah> any history behind those
[14:00] <shuah> mchehab: I can send the code I have now to start discussion from - ok with you
[14:03] <shuah> it is 3 patches 1. media-controller core, 2. au0828, and 3. snd-usb-audio
[14:13] <mchehab> ok
[14:14] <shuah> maybe we have to map both devices control and pcm associated with au0828
[14:15] <shuah> devices get created sound-core - not an issue. I just have to figure out where to insert media specific hooks
[15:14] <alexcoding> Hello, has anyone had the experience of compiling v4l dvb utils for android that could help me? :\
[15:55] <mchehab> shuah: yes, the media controller support should be there at the core
[15:56] <mchehab> once MC is enabled, it should be creating it for all devices that the core creates
[15:56] <shuah> ok
[15:58] <APic> Ok.
[15:59] <shuah> all the MC hooks are under snd-usb-audio at the moment - once this solution is ironed out, we can move it under core
[16:01] <shuah> the MC support in alsa at the moment is anchored with a quirk on au0828
[16:21] <mchehab> shuah: does snd-usb-audio have visibility about what devices are created?
[16:22] <shuah> yes it does
[16:23] <shuah> it does the parsing and uses core helper functions to create the type of devices it needs to create - for example PCM
[16:23] <mchehab> ok
[16:23] <shuah> I think I have a handle on this now - give me a couple of hours, I might be able to send you graph that looks sane :) Keeping my fingers crosses
[16:23] <mchehab> ok
[16:30] <mchehab> shuah: it seems that the controlC0 is associated with the audio mixer entity
[16:30] <mchehab> although it seems to control other things, like the power state of the device
[16:31] <mchehab> case SNDRV_CTL_IOCTL_POWER_STATE:
[16:31] * mchehab is looking at sound/core/control.c
[16:34] <mchehab> hverkuil, sailus, pinchartl: mapping alsa entities and devnodes don't seem to be an easy task
[16:34] <devinheitmueller> I am not confident anything uses SNDRV_CTL_IOCTL_POWER_STATE nowadays. I'm 95% certain that PulseAudio doesn't, which is what everything gets routed through nowadays.
[16:35] <mchehab> devinheitmueller: pa uses only a subset of alsa features
[16:35] <mchehab> afaikt, it doesn't implement mmap()
[16:35] <devinheitmueller> Sure, but most application use ALSA through pulseaudio emulation.
[16:35] <mchehab> with could be a problem on some apps
[16:35] <mchehab> that's why even desktop distros offer alternatives to pa, like jack
[16:37] <shuah> right control device is used for mixer and other things
[16:37] <mchehab> what I'm concerned at this moment is how to properly map ALSA devnodes and data streaming entities using MC
[16:38] <mchehab> I mean: I'm not sure if we can do a 1:1 relationship between /dev/snd/controlC1 and the mixer entity
[16:38] <devinheitmueller> mchehab: nope, you can't.
[16:39] <devinheitmueller> You're probably going to need to have the driver developer explicitly specify the relationship. It's too easy to have a single mixer control effect multiple PCM devices, or multiple mixers effecting a single PCM device.
[16:39] <mchehab> the "common" usage of the controlC? seems to be to set the mixer
[16:39] <mchehab> well, the PCM devices are different beasts
[16:39] <mchehab> and are likely simpler to be mapped
[16:40] <mchehab> as they're directly associated with audio capture or audio playback
[16:40] <mchehab> not sure if I express myself clear
[16:40] <mchehab> I mean:
[16:40] <devinheitmueller> As long as any automatic heuristic for selection can be overridden, I certainly have no objection. I've seen too many boards where you need to do something unusual to rely on it happening automagically.
[16:40] <shuah> how about mapping PCM capture and playback devices - those are the ones that interact with the the rest of the media drivers
[16:41] <mchehab> we can map a MC capture entity to a PCM capture devnode
[16:41] <shuah> right that is what I am doing now - just the capture device
[16:42] <shuah> I don't think we have any issues with PCM capture device at the moment
[16:42] <shuah> The question is do we have to map control device or not
[16:42] <devinheitmueller> shuah: at some point you should get a raw capture board with multiple inputs - that will likely expose edge cases you're not thinking of.
[16:42] <devinheitmueller> In this case the 950q is probably too simplistic since it only has a single video input, single audio input, and single mixer control.
[16:43] <mchehab> yes
[16:43] <mchehab> PC customer hardware it too simple
[16:44] <shuah> Yes I agree - on the other hand - this is how we work right evolve the solution :)
[16:44] <mchehab> a SoC for TV sets/STBs would likely offer multiple PCM capture/playbacks...
[16:44] <devinheitmueller> Well it's been fifteen years and we still haven't properly handled PC hardware, so I wouldn't speak too fast in claiming that it's "too simple". :-)
[16:44] <mchehab> and, eventually, multiple mixers
[16:45] <mchehab> devinheitmueller: too simple when comparing with SoC's
[16:46] <mchehab> actually, in terms of ALSA, PC tv hardware is even simpler than a standard audio card
[16:47] <devinheitmueller> mchehab: no doubt.
[16:47] <devinheitmueller> Although I've got some PC tv hardware that would rival audio cards in complexity. :-)
[16:48] <mchehab> yeah, there are some
[16:49] <mchehab> the audio part of cx25821 are more complex than audio cards... as it has 16 pcm captures and/or playbacks
[16:49] <larsc> the control device controls basically all mixer and routing settings for all components that are part of the device
[16:49] <mchehab> the current driver is a simpler than what the device provides internally
[16:51] <devinheitmueller> Yeah, I've got a few cx25821 boards here.
[16:52] <mchehab> larsc: yep, but I'm not sure if it is just the mixer/pipeline settings it is controlled there, or if it can control other hardware entities
[16:52] <devinheitmueller> The Viewcast boards I have here are also really annoying since they multiple volume controls to cover the same PCM device (both a pre-amp and the audio decoder volume)
[16:53] <mchehab> yeah, viewcast boards are complex
[16:53] <mchehab> well, devices for "professional" usage (either SoC or PCI/ePCI) are complex
[16:54] <mchehab> media controller should be able to properly map such hardware
[21:17] <tnt> this is going to sound liek a noob question but how does i2c_get_clientdata work is i2c_set_clientdata was never called ? Does it magically init it to first devm_kzalloc call or something ?
[21:26] <headless> tnt, it'll just return NULL
[21:27] <tnt> But I'm looking at ov9650.c for instance and seems like they definitely expect i2c_get_clientdata to return valid stuff and yet, I can't find where it's initialized.
[21:28] <tnt> git grep i2c_get_clientdata in drivers/media/i2c shows 136 matches. the same for set_cliendata shows only 2 !
[21:31] <headless> looks like it's set by V4L2 core
[21:32] <headless> drivers/media/v4l2-core/v4l2-common.c
[21:33] <tnt> headless: ah yes indeed ! thanks.
[21:34] <tnt> so I actually need my "struct v4l2_subdev" to be first member of my "private" struct
[21:58] *** sailus_ changes his alias to sailus
[22:09] *** belektro changes his alias to Guest47494
[22:24] <shuah> mchehab, hverkuil, pinchartl: I am adding alsa devnode defines after MEDIA_ENT_T_DEVNODE_DVB_NET i.e MEDIA_ENT_T_DEVNODE_ALSA_MIXER will be(MEDIA_ENT_T_DEVNODE + 9) and ALSA_PLAYBACK and ALSA_CAPTURE will be +10 and +11
[22:25] <shuah> Do you want me to leave MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) alone to avoid userspace breaks
[22:25] <shuah> I could point MEDIA_ENT_T_DEVNODE_ALSA to MEDIA_ENT_T_DEVNODE_ALSA_CAPTURE, but that would leave a hole at +3
[22:26] <mchehab> shuah: do whatever you need on your patches... we'll need to discuss the approach taken latter when fixing the messy things at MC
[22:26] <mchehab> no MC patches will be added upstream until we fix this
[22:26] <shuah> ok sounds good
[22:26] <shuah> no problems
[22:27] <mchehab> but you should go ahead, as this will help to map other hidden issues that might be there
[22:29] <shuah> yes I am working on it now - not going to wait. These can be fixed later
[22:30] <shuah> maybe you can pull these into experimental branch for wider coverage
[22:31] <mchehab> yeah, I can do that