Re: [PATCH 0/4] media Kconfig reorg - part 2

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Mauro,

On Wed, Mar 25, 2020 at 10:38:20PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 25 Mar 2020 16:36:31 -0300 Helen Koike escreveu:
> > On 3/25/20 1:03 PM, Mauro Carvalho Chehab wrote:
> > > That's the second part of media Kconfig changes. The entire series is
> > > at:
> > > 
> > > 	https://git.linuxtv.org/mchehab/experimental.git/log/?h=media-kconfig  
> > 
> > I made a quick experiment (using this branch) with someone who works with the kernel for his master degree, but doesn't have much experience in kernel development in general.
> > I asked him to enable Vimc (from default configs, where multimedia starts disabled).
> > He knows that Vimc is a virtual camera driver, and this is how he behaved:
> > 
> > === Start of experiment:
> > 
> > * He pressed '/' and searched for vimc to see the location path.
> > * Then he enabled "Multimedia support" and went straight to "Media drivers" (which just shows USB and PCI).
> > * He went back to "Multimedia support", entered "Media device types" and enabled "Test drivers".
> > * He went back to "Media drivers" again and didn't find Vimc (nothing changed in this menu).
> > * He seemed a bit lost, going back and forth in the menus a couple of times.
> > * Then he pressed '/' again to search for vimc and see the location path, and he realized that there
> > should be an option called "V4L test drivers" under "Media drivers" that is not showing up.
> > * He went back to "Media device types" again and start re-reading the options.
> > * He selected "Cameras and video grabbers" ant went back to "Media drivers".
> > * He sees "V4L test drivers", selects it, and enter this menu.
> > * He selects "Virtual Media Controller Driver".
> > 
> > I asked his impressions, and he mentioned that he thought that enabling just "Test drivers" would be enough, without need
> > to combine "Test drivers" with "Cameras and video grabbers".
> > He also asked me why virtual drivers should be hidden, and he mentioned that the word "Virtual" in front would be enough.
> > 
> > Then I showed him he could have disabled the option "Filter devices by their types" to see everything at one (which he didn't
> > realized by himself until that moment, nor tried it out to see what would happen).
> > 
> > He mentioned that hiding is nice, because it shows less options, but not very nice to search for something.
> > He also mentioned that if he had understood the filter mechanism from the start, he would have disabled "Filter devices by their types" sooner.
> 
> That's easy to solve: all it needs is to add something similar
> to this at drivers/media/Kconfig:
> 
> 	+	comment "Drivers are filtered by MEDIA_SUPPORT_FILTER"
> 	+		visible if MEDIA_SUPPORT_FILTER
> 	+
> 	+	comment "All available drivers are shown below"
> 	+		visible if !MEDIA_SUPPORT_FILTER
> 	+
> 	menu "Media drivers"
> 
> 	source "drivers/media/usb/Kconfig"
> 
> > === End of experiment
> > 
> > This was just one experiment from one person, I'll see if I can get some other people from lkcamp.dev group to also check
> > and send us their impressions. I think it would be nice to get more data about user experience, from people that are not used to
> > kernel development (kernel dev newbies for instance).
> > 
> > Just another remark from me:
> > 
> > From the default config, "Media drivers" shows USB and PCI, 
> 
> Well, assuming that there are 2 billion computers, 1% with Linux
> installed, and 10% of them have a media device (camera or TV),
> we have about 2 millions of people running Linux. That excludes
> Android and Embedded devices, where people usually don't touch.
> 
> During an entire year, there are about 4000 of Kernel developers 
> that has at least one patch accepted upstream (this number
> includes developers for Android and other SoCs). Also, the 
> number of Kernel developers submitting patches upstream for the
> media subsystem is around 20-40 people along an year.

$ git log --since 2019-01-01 --until 2020-01-01 --no-merges -- drivers/media/ | grep '^Author: ' | sort | uniq -c | wc -l   
215

There's some duplication of e-mail addresses, but it's still roughly an
order or magnitude bigger (and it's not counting staging, headers or
documentation).

> So, about 99,9998% of the users using the media subsystems aren't
> Kernel hackers. I bet that almost all of those will either need
> to enable USB or a PCI driver.

And the extremely vast majority of these will never enable a kernel
option because they will never compile a kernel. They don't even know
what a kernel is :-)

> Granted, 99,9998% seems too optimistic, but, assuming that this
> would reduce to something like 80% (e. g. only 200 users
> would ever try to build a media driver, with is a *very conservative*
> number) this is still a lot more than the number of media Kernel
> developers.
> 
> Also, a Kernel hacker will sooner or later find a way to enable it.
> A normal user may find it a lot more trickier and will very likely
> require more support, if the menus are too technical and the
> default options are wrong.

I'm not sure to follow you. Are you implying that this patch series,
which Helen has tested against a real user, not an experienced kernel
hacker, may make the configuration options more difficult for kernel
hackers, but improves the situation for users ?

> 
> -
> 
> Even with that, based on your small experiment (of someone from the
> area), I suspect that, if you had asked him to enable, for example,
> em28xx or dvbsky (with are some of the most popular drivers
> those days), he would be able to enable it a lot faster.

This is the *only* real piece of evidence we have, let's not assume we
know better.

> > and selecting those doesn't do anything, and people can even think
> > that, if they want to enable an USB device, just enabling the USB option there is enough (which is not), since no drivers
> > shows up.
> 
> It is hard to comment on individual experiments. In the past, our
> Kconfig system were like that: written for technical people with
> background on computer engineering and some experience building the
> Kernel.
> 
> E.g. people that knows that "/" activates a search mechanism at
> the Kernel building system.
> 
> We usually had to spend *a lot of time* both on IRC and on e-mail
> explaining people that just want to have their card supported,
> how to do that. After the reorg (with added those more user-faced
> interfaces), the number of people with problems reduced a lot.

Don't you think that could come mainly from better support for media
devices in distributions ?

> Btw, if one tries to compile from media-build (with lots of users
> do), this is even more relevant.

Can you quantify "lots of users" ?

-- 
Regards,

Laurent Pinchart

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel