**** BEGIN LOGGING AT Fri Jan 01 02:59:59 2016 Jan 01 07:36:59 Jan 01 07:41:06 indeed Jan 01 07:52:42 ↑ Jan 01 07:58:09 * jonwil is stuck :( Jan 01 07:59:26 * brolin_empey is socially isolating himself, as usual. Jan 01 08:02:55 AD MMXVI has arrived in UTC -8 hours. Jan 01 08:03:32 in America/Vancouver . Jan 01 08:21:04 is it 2016 already? i still don't feel any different Jan 01 08:24:13 #include Jan 01 08:26:50 sufficientlyadvanced.technology Jan 01 08:26:58 dog.cat Jan 01 08:27:04 yawn(); Jan 01 08:28:11 (MOS)FETish? Jan 01 10:50:04 Pali: looks like the bug in isp1704 was present even before transition to usb_phy Jan 01 10:50:46 see http://lxr.free-electrons.com/source/include/linux/usb/otg.h?v=3.1#L143 Jan 01 11:19:54 http://lxr.free-electrons.com/source/include/linux/usb/otg.h?v=2.6.36#L142 Jan 01 11:19:54 http://lxr.free-electrons.com/source/include/linux/usb/otg.h?v=2.6.35#L149 Jan 01 11:19:57 freemangordon: ^^^^ Jan 01 11:20:37 this is really stupied they switches signature between 2.6.25 and 2.6.36 Jan 01 11:20:46 oh, the change was introduced between 35 and 36 Jan 01 11:20:52 ups Jan 01 11:20:56 25 and 36 Jan 01 11:21:17 Pali: however, I already sent a patch, you're maintainer there :) Jan 01 11:21:22 yea Jan 01 11:21:38 s/25/35/ Jan 01 11:21:51 yep, 35 Jan 01 11:22:02 driver was itroducted in 2.6.37-rc1 Jan 01 11:22:04 huh, changes like that break precompiled blobs usually Jan 01 11:22:16 maybe they do it on purpose sometimes? Jan 01 11:22:24 nope, driver is broken since inclusion Jan 01 11:22:34 nah, they simply overslept that Jan 01 11:22:44 yes, broken since the inclusion Jan 01 11:24:51 Pali: whom else besides you from the n900 guys to cc re rootfs corruption problem? Jan 01 11:25:04 pavel? sre? aaro? Jan 01 11:26:43 yes, also tony Jan 01 11:27:08 tony is in --to :) Jan 01 11:27:09 and maybe also nishanth Jan 01 11:27:13 he is the author Jan 01 11:27:17 ah, yes Jan 01 11:56:47 Pali: could you try to pint Tomi re "Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator" as well, as it seems he doesn't saw my ping Jan 01 11:57:06 *didn't see Jan 01 11:57:15 * freemangordon needs moar coffee Jan 01 11:57:37 freemangordon: hm... I do not see any yor new email Jan 01 11:57:43 it is not new Jan 01 11:57:59 Pali: 25.12.2015 15:36 Jan 01 11:59:36 got it Jan 01 12:02:04 ping sent Jan 01 12:02:18 thanks Jan 01 12:02:38 fremangordon, can you resend patch "ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks" as Tomi asked? Jan 01 12:02:58 that's what I'm doing :) Jan 01 12:03:06 :-) Jan 01 12:03:10 but I need to revert that one and make a new one Jan 01 12:03:20 look at the thread Jan 01 12:08:07 Pali: hmm, looks like it *is* upstreamed Jan 01 12:09:24 why then we still have that patch in linux-n900 and is applied? Jan 01 12:09:24 ? Jan 01 12:09:36 no idea Jan 01 12:11:08 Pali: see 0eb0dafb674cd6bfac2e3204b2f8b907e26b1138 Jan 01 12:11:17 so question is: what is applied?? Jan 01 12:11:39 NFC Jan 01 12:12:03 seems what is applied is still correct Jan 01 12:12:17 however, I've reverted those 2 patches, going to test Jan 01 12:17:11 Pali: or those 2 are the reason for non-working backlight fade, will see in a minute Jan 01 12:17:27 test Jan 01 12:17:33 at least it still boots Jan 01 12:17:38 to h-d that is Jan 01 12:20:41 Pali: well, backlight fade still does not work, but it boots, so those 2 patches seem to be not needed Jan 01 12:21:00 ok Jan 01 12:26:17 Pali: ok, what now? Jan 01 12:26:35 need to figure out what that patch is doing :-) Jan 01 12:26:44 which one? Jan 01 12:33:28 those two in linux-n900 tree... Jan 01 12:33:58 maybe nothing, they patch files no longer needed Jan 01 12:34:11 but ok, do it Jan 01 13:11:51 Pali: who was monitoring the slide gpio? Jan 01 13:12:08 mce Jan 01 13:12:14 hmm Jan 01 13:13:17 and hald-addon-omap-gpio Jan 01 13:22:10 Pali: we can bindmount in /sys :) Jan 01 13:22:39 and, how you create dynamic content with poll support? Jan 01 13:22:50 no idea :) Jan 01 13:22:56 rather fixing mce other libs to use new api Jan 01 13:23:01 which is in upstream kernel Jan 01 13:23:08 well, ok Jan 01 13:23:13 and for sscd create LD_PRELOAD library Jan 01 13:23:40 or check if sscd really needs to touch gpio... (if configuring externally is not enough) Jan 01 13:28:57 funny thing those rdepends: http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/mc/4.8.14-0maemo1/ Jan 01 14:53:52 KotCzarny: because of provides Jan 01 16:51:52 pali: i find it quite hilarious that mc is a dependency for qml-browser etc Jan 01 16:56:15 mc provides mcedit which is able to view text files Jan 01 16:56:43 and some of those qml-browser dependency packages depends on something which nees to view text files Jan 01 16:57:15 and so you mc via mcedit is one of alternatives for that dependency Jan 01 16:57:48 so its not a 'required' but might be 'suggested' ? Jan 01 17:03:20 i once had qml-browser on both my N900, but it never pulled mc. that's "new" dependency? Jan 01 17:04:24 sicelo, it might showed in 'suggested' Jan 01 17:04:28 or 'recommended' Jan 01 17:04:36 've Jan 01 17:33:14 md ~/c3torrents; for x in `wget -q -O- http://cdn.media.ccc.de/congress/2015/h264-hd/ | grep '\.mp4'|sed 's/.*.*//'`; do wget -q -P ~/c3torrents -c http://cdn.media.ccc.de/congress/2015/h264-hd/$x.torrent; done Jan 01 18:37:45 Pali: and what is the problem with gpio-switch driver? Jan 01 18:38:30 I mean - why not continue to use it, until there are no more stuff to fix and then migrate the userspace to the new interface Jan 01 18:48:04 freemangordon: because it does not work :-) Jan 01 18:48:20 any idea why it does not work? Jan 01 18:48:21 it just export static data so mce and other stuff does not crash Jan 01 18:48:34 I know, but why not make it wokring? Jan 01 18:48:34 because only one driver can use gpios Jan 01 18:49:01 you cannot make it working without rewriting linux kernel module subsystem Jan 01 18:49:02 ok, and who uses slide, cam_focus, etc? Jan 01 18:49:26 other drivers, gpio event input Jan 01 18:49:27 ... Jan 01 18:49:49 Pali: there is gpiod_export_link Jan 01 18:50:10 which export them to /sys/class/gpio// Jan 01 18:50:24 no, ^^^ export it in your driver dir Jan 01 18:50:51 or wherever you make symlink to point to Jan 01 18:51:11 Pali: see http://lxr.free-electrons.com/source/drivers/gpio/gpiolib-sysfs.c#L638 Jan 01 18:51:43 so it just create symlink Jan 01 18:51:59 yes Jan 01 18:52:05 thats now enough Jan 01 18:52:11 I know Jan 01 18:52:11 see format of gpio-switch Jan 01 18:52:15 yes Jan 01 18:52:35 gpiod_export_link is useless here... Jan 01 18:52:44 I do not see any advantages for it Jan 01 18:53:47 Pali: the other option is to create (daemon, driver) that bindmounts what is needed by maemo while doing poll() Jan 01 18:54:13 isn;t it possible to use fuse or somesuch? Jan 01 18:54:20 how do you want to simulate poll() Jan 01 18:54:20 ? Jan 01 18:54:40 err.. how do you want to check if application is doing poll()? Jan 01 18:54:41 only divers can do it? Jan 01 18:55:09 all this is just more work as rewriting existing code to use new api Jan 01 18:55:41 and all the code that needs to be rewritten is foss? Jan 01 18:55:57 also, keep in mind we should keep backwards compatibility as well Jan 01 18:56:04 except sscd... yes Jan 01 18:56:22 rather create LD_PRELOAD lib Jan 01 18:56:35 hmm Jan 01 18:56:40 this should be easier Jan 01 18:56:53 then there is no need to fix mce, hal, etc Jan 01 18:57:07 if we're going to LD_PRELOAD Jan 01 18:57:20 rather use LD_PRELOAD just for sscd Jan 01 18:57:26 and fix other stuff Jan 01 18:57:32 but I still think LD_PRELOAD is very nasty hack Jan 01 18:57:47 yes, reason why only for sscd Jan 01 18:58:36 Pali: well, I'll check if there is a way to create poll()-able files from userspace Jan 01 18:58:48 no Jan 01 18:58:56 you cannot do that Jan 01 19:00:53 Pali: what about ptty? Jan 01 19:01:29 ehm... all this sounds like worse hack as LD_PRELOAD Jan 01 19:01:34 or it is char device? Jan 01 19:01:46 it is char device Jan 01 19:02:08 won;t work then Jan 01 19:02:12 anyway, if you create such thing somehow, you have one big problem Jan 01 19:02:21 you cannot call mkdir in sysfs Jan 01 19:02:23 which is? Jan 01 19:02:26 on which you do mount --bind Jan 01 19:02:39 gpio-switch doe it for me already Jan 01 19:02:44 *does Jan 01 19:02:52 so you still need kernel changes for it Jan 01 19:03:09 sure Jan 01 19:03:27 sounds bad Jan 01 19:03:35 but this is just a small driver we have to support out of the tree Jan 01 19:03:50 too much work Jan 01 19:03:57 and no idea if it works correctly Jan 01 19:04:09 really it is easier to patch existing applications Jan 01 19:04:27 and for sscd check if it really needs to use gpio Jan 01 19:04:49 e.g. if external daemon for configuring cmt gpio is not enough Jan 01 19:05:06 and if not, LD_PRELOAD for sscd Jan 01 19:29:02 Pali: could fuse do the job? Jan 01 19:29:21 yes... Jan 01 19:29:41 ... but this is even worse as all above .... Jan 01 19:29:49 isn;t that upstreamed? Jan 01 19:29:53 fuse I mean Jan 01 19:30:32 seems like no Jan 01 19:30:38 fuse is in upstream... Jan 01 19:30:49 oh, great then Jan 01 19:30:51 but this is really stupid... Jan 01 19:30:55 and also harder Jan 01 19:30:56 why? Jan 01 19:31:05 because it does not solve original problem Jan 01 19:31:12 just add another layer of other problems Jan 01 19:31:15 related to fuse Jan 01 19:31:37 we'll just need to implement gpio-swith by using fuse, ain;t? Jan 01 19:31:48 I really want to avoid all those layers and hacks... Jan 01 19:32:52 Pali: and what you'll do on neo900 or any other device, which has different gpio for proximity, for example. Again, fix mce and whatnot? Jan 01 19:32:55 Brewster had daar geen problemen mee Jan 01 19:32:59 oops. darmn. sorry. Jan 01 19:33:01 wrong channel. Jan 01 19:33:32 Pali: we should somehow split mce from the HW Jan 01 19:33:39 mce and the others Jan 01 19:33:48 split? Jan 01 19:34:13 ok, make some kind of "impedance matcher" between mce and the HW Jan 01 19:34:40 what if your camera "button" is not a HW switch, but soft button? Jan 01 19:34:49 do you get me? Jan 01 19:35:06 we simply cannot hack mce for every possible HW config Jan 01 19:35:21 thus we need some layer to translate Jan 01 19:35:27 do not know... Jan 01 19:37:28 Pali: my idea is - gpio-switch functionality looks reasonable. Implement a piece of SW, in userspace if possible, which can be tuned for various HW platforms that implements gpio-swicth functionality Jan 01 19:40:22 Pali: the point is - the existing kernel interface that exports gpios by number is really stupid IMO - what if you have 2 HW revs of one and the same device, 1st using gpio1 for some function, the 2nd using gpio10 for the same Jan 01 19:41:00 your userspace simply have no way to find which is the correct gpio to use Jan 01 19:41:58 the other option is to extend the kernel interface gpio export functionality, to attach some meningful "name" to the exported gpio Jan 01 19:42:18 instead of that cryptic gpioN Jan 01 19:42:41 Pali: what do you think? ^^^ Jan 01 20:01:41 i'm not up to date with your discussion on this, guys, so forgive me if I propose somehing stupid Jan 01 20:01:59 but the standard way wouldn't be to prove /dev/input devices? Jan 01 20:02:21 those could use gpio driver but provide a common interface to user space Jan 01 20:04:22 ceene: gpio could be output as well Jan 01 20:05:18 and there *is* a standard interface in /sys, just not smart enough IMO Jan 01 20:06:06 I am going to send an RFC on lkml for providing a way to export gpio via sysfs under an user-provided name, instead of gpioN Jan 01 20:06:46 this should be easily doable, struct gpio_desc already has a member called "label" Jan 01 20:23:54 ((make some kind of "impedance matcher" between mce and the HW)) that's called HardwareAbstractionLayer Jan 01 20:25:55 ((what if you have 2 HW revs of one and the same device)) then you regularly use some hardwired hw revision keying that kernel or userspace reads out Jan 01 20:26:41 or even flasher does, and chooses the right version of firmware to flash to device Jan 01 20:26:55 see N900 ;-) Jan 01 20:27:22 there's a version that swaps blue and red (iirc) LED of LP5523 indicator light Jan 01 20:27:42 check lp5523.ko sources, I think it's in there Jan 01 20:34:01 DocScrutinizer05: or board support package, or whatever you want to call it. the point is that we *must not* hardcode paths like /sys/i2c-2-15/blabla Jan 01 20:34:09 the same goes for gpios Jan 01 21:00:44 freemangordon: those events are export by other drivers, like input driver, etc Jan 01 21:01:14 input kernel subsystem has for this purpose special "switch" events Jan 01 21:01:24 which perfectly match this needs Jan 01 21:01:33 and they are already in upstream for n900! Jan 01 21:34:33 it seems like it would be helpful to document everything on the system that touches /sys/* Jan 01 21:34:58 oh wait I think I did that before Jan 01 21:38:57 or not Jan 01 21:43:28 wiki.maemo.org --> Porting --> Kernel Jan 01 21:44:13 yeah thats a great start, this one will be more comprehensive though :P Jan 01 21:46:00 Pali: who exports "slide"? Jan 01 21:50:29 freemangordon: input Jan 01 21:50:40 Pali: see, if there is an existing driver classes for all the various switches and sensors on n900, I am fine with reusing them Jan 01 21:51:03 freemangordon: should be Jan 01 21:51:15 because other kernel drivers uses those GPIOs already Jan 01 21:51:21 hmm, ok Jan 01 21:51:23 exception is CMT part Jan 01 21:51:36 CMT should be fine, as it is Nokia specific Jan 01 21:51:48 but there is nokia-modem.pm=1 (export via /sys/class/gpio/) you knwo Jan 01 21:51:50 *know Jan 01 21:51:53 yeah Jan 01 21:54:15 * freemangordon boots 4.4 to see where in /sys/class/input is exported "slide" Jan 01 21:55:19 freemangordon: no /dev/input/event* Jan 01 21:55:43 so, we should create a driver to export it? Jan 01 21:55:56 soory for the maybe stupid questions Jan 01 21:56:00 *sorry Jan 01 21:56:24 you need to use /dev/input for it Jan 01 21:56:35 but now going to look into source code Jan 01 22:07:14 freemangordon: you need to compile gpio-keys.ko Jan 01 22:07:25 and then via /dev/input/event ask for switch status Jan 01 22:08:00 currently gpio-keys.ko is disabled in linux-n900 tree CONFIG_KEYBOARD_GPIO=m is needed for it Jan 01 22:11:12 Pali: and how do you distinguish between various switch types? is there interface for it? Jan 01 22:11:39 Pali: and what "ask" means? poll()? Jan 01 22:11:39 freemangordon: yes, each switch has its own "code" Jan 01 22:11:46 code? Jan 01 22:11:54 like key press Jan 01 22:12:04 every key has its own code Jan 01 22:12:54 keypad_slide --> gpios = <&gpio3 7 GPIO_ACTIVE_LOW>; /* 71 */ --> linux,code = <0x0a>; /* SW_KEYPAD_SLIDE */ Jan 01 22:13:01 all is defined in DTS Jan 01 22:13:03 oh, so we open all the stuff in /dev/input and wait for KEY_SLIDE on all of the descriptors? Jan 01 22:13:18 not all stuff in /dev/input Jan 01 22:13:33 just one device which has that name gpio-keys Jan 01 22:14:10 where is that "name" defined? in /sys/input/devices? Jan 01 22:21:56 Pali: Is the intent that upstream kernel works with stock bme or will upstream kernel need your bme replacement? Jan 01 22:23:43 actually, it doesn't matter :) Jan 01 22:23:50 jonwil: it needs bme-replacement Jan 01 22:23:53 ok Jan 01 22:26:16 are we getting kernel 4.x yet? :) Jan 01 22:27:56 freemangordon: name is defined in DTS too Jan 01 22:28:19 jonwil: upstream kernel works with bme replacment Jan 01 22:28:30 *already* Jan 01 23:03:47 freemangordon: ((point is that we *must not* hardcode paths)) must not as in "upstream will kill us" or any technical reasons? My take on this is a tad "anachronistic" since I think an embedded device doesn't need a general purpose kernel but should use its own tailored-to-fit lean kernel derived from upstream by pruning Jan 01 23:04:15 having an upstream kernel is great for many reasons Jan 01 23:04:40 for one - grsecurity :) Jan 01 23:05:02 well, having an upstream jkernel doesn't mean you need *all* of that stuff, most is cruft for your particular device Jan 01 23:05:37 I don't see why you would hardcode paths if there are more sensible ways to do it that will save time/problems in the future :) Jan 01 23:05:54 Either way, I'm happy with the work that seems to be done! Jan 01 23:06:10 because such generic stuff costs storage and memory and runtime Jan 01 23:07:40 e.g. for hostmode we had to kick out a shitload of cruft that got in the way with USB enum and hubs and whatnot Jan 01 23:08:27 but I don't want to argue, I know I won't make a point against 99% of devels Jan 01 23:09:59 I just see that basically every commercial embedded device I've ever seen has his own private branch of kernel, with patches sometimes eventually getting upstreamed, sometimes never Jan 01 23:10:15 which is dreadful for security and interoperability Jan 01 23:10:36 I don't think some generic path resolve will use that much mem/storage/runtimecpu Jan 01 23:10:39 err why? as long as upstream patches apply to your local branch? Jan 01 23:10:52 because it is a PITA to maintain Jan 01 23:11:02 Pali: Do we have a list somewhere of all interfaces under /sys and /proc that have changed between N900 stock kernel and upstream kernel? Jan 01 23:11:04 keeping track of all the security patches, let alone bug fixes Jan 01 23:11:09 jonwil: he left Jan 01 23:11:13 oh ok Jan 01 23:11:27 tzz, that's the "I'm too lazy" argument that naver resulted in technically optimized solutions Jan 01 23:11:27 jonwil: maybe the wiki article he mentioned helps (I guess you saw it already) Jan 01 23:11:43 nope, that doesn't help so much Jan 01 23:13:12 as long as you do smart 'proprietary' patches to your branch, upstream security and maintenance patches should apply without any conflict Jan 01 23:13:48 but why bother if you can just use the latest version? why spend many hours on something that is already taken care of Jan 01 23:13:54 anyway, I also don't want to argue :) Jan 01 23:16:19 because of the headache freemangordon has with "what do we do with changing/differing GPIO numbers on same platform" Jan 01 23:16:41 for example Jan 01 23:17:38 embedded is *way* more different from platform to platform than your average PC differs between Dell and younameit Jan 01 23:18:16 and the complexity of those differences typically is of the class that has no proper means to deal with it at all in a generic kernel Jan 01 23:18:19 my embedded ARM home server runs mainline linux Jan 01 23:18:51 kerio: mine too :) Jan 01 23:18:59 my arm laptop too Jan 01 23:19:02 and it's awful Jan 01 23:19:06 because it's not bsd Jan 01 23:19:10 lol. Jan 01 23:19:19 kerio: then prolly because some poor sods upstreamed the patches needed to make the linux run on that platform Jan 01 23:19:29 indeed! Jan 01 23:19:40 maemo has *two* poor sods Jan 01 23:19:41 DocScrutinizer05: what's with the hate? Why isn't it awesome that we can use stuff like btrfs on ARM home servers? Jan 01 23:19:56 huh? Jan 01 23:19:59 Some things takes so much work to backport to older versions, when you can simple use the latest LTS / mainline version Jan 01 23:20:03 you totally lost me Jan 01 23:20:08 poor sods -> great people Jan 01 23:20:12 :) Jan 01 23:20:14 is my point mostly Jan 01 23:20:18 guess I misunderstood Jan 01 23:20:33 DocScrutinizer05: being able to run mainline means that you get access to new features Jan 01 23:20:39 and they can be good Jan 01 23:20:46 so what? Jan 01 23:21:28 That can often means better performance, lower memory usage, more bug fixes, etc, etc. Jan 01 23:21:40 Better crypto, other things relevant to embedded Jan 01 23:22:26 in the old day every PC had to compile its own kernel. And that had its advantages since the kernel was small and fast and tailored to fit. And there was zilch problem to run the "make kernel" on your installation interim system. You did that one and voila Jan 01 23:22:48 I still do that for all my machines Jan 01 23:22:56 And you can also do that for the N900 with mainline/upstream Jan 01 23:22:58 DocScrutinizer05: that's not at all what "mainline kernel" means Jan 01 23:23:05 or, rather Jan 01 23:23:13 that's not in contradiction with Jan 01 23:24:19 it's your arguing about mainline. I never had objections against mainline, I only said each embedded has its own branch where you keep the stuff that hasn't yet, or can't at all get upstreamed Jan 01 23:24:40 there are quite some arm devices where everything is upstreamed :) Jan 01 23:24:51 and you might want to prune that branch to kick out obviously cruft items Jan 01 23:25:04 I think for the n900, where the bits are not upstreamed, they are in some branch. Like with amd64 platform drivers Jan 01 23:25:06 ARM doesn't need PCI-support Jan 01 23:25:40 nor fan sensor support Jan 01 23:25:53 nor weird AMD graka drivers Jan 01 23:26:09 Jetson TK1 has PCI slots Jan 01 23:26:15 TX1 has them too Jan 01 23:26:24 and the ARM servers have them too Jan 01 23:26:28 :o Jan 01 23:26:30 N900 has _not_ exactly my point Jan 01 23:26:36 You said "ARM" :) Jan 01 23:26:42 neo900 feature request: pci express Jan 01 23:26:45 :-P Jan 01 23:26:55 merlijn@deepwater ~ $ sudo zgrep CONFIG_PCI /proc/config.gz Jan 01 23:26:55 # CONFIG_PCI is not set Jan 01 23:27:00 ^arm machine Jan 01 23:27:02 not hard to disable :) Jan 01 23:27:52 ok, and what do you do when it starts to be hard or impossible? Jan 01 23:28:08 you file a bug Jan 01 23:28:14 it's linux, not systemd Jan 01 23:28:29 gnu/linux in the case of the n900 Jan 01 23:28:32 * Wizzup hides Jan 01 23:28:36 like with lis302 driver which is completely brainfucked in upstream, and will cut through your battery in no time Jan 01 23:28:37 the maintainer yells at the other devs, not at the users Jan 01 23:28:59 Wizzup: no, "linux" is quite specifically correct here Jan 01 23:29:06 kerio: I realised ;-) Jan 01 23:29:08 I just felt trolly Jan 01 23:29:13 I'll go and hit the sack :) Jan 01 23:44:07 DocScrutinizer05: reasons are technical, I give a shit about politics and you know it :) Jan 01 23:45:49 very similar to what Wizzup said - the cost of maintenance and platform independence Jan 01 23:47:16 why we should have HW specific stuff if we can skip it Jan 01 23:48:48 for example - if we use generic interface, the board package could simply contain a script creating HW specific symlinks for various devices existing in the platform implementing predefined API Jan 01 23:49:41 or what Pali said ^^^ - using generic /dev/input interface with board file providing the HW specific settings Jan 01 23:50:28 DocScrutinizer05: also, believe it or not, but upstream kernel runs waaay faster that stock, when it works ofc Jan 01 23:51:08 we have things like neon-optimized functions, RCU, lots of optimizations, etc, etc Jan 01 23:52:05 I am not thinking N900 or Neo900 here, but Maemo Jan 01 23:52:36 from the POV of the userspace it should not matter what platform it is and whether it is embedded or server Jan 01 23:54:30 also, having HW support upstreamed doesn't mean you cannot use device specific kernel - and that is what we use to boot upstream on N900, there is rx51_defconfig in arch/arm/configs, which enables only what is needed on N900 Jan 01 23:54:44 then you run into sever trouble, since userland will need to behave differently for different platforms. This starts with N800 vs N900, where we either have pop-out camera or two camreas and a camdoor for one of both Jan 01 23:55:38 but we should not run in troubles for simple stuff like gpio swithes and sensors, yet we do as all the userspace is tailored for a specific HW Jan 01 23:55:44 you can't expect same kernel API on different platforms Jan 01 23:55:52 why? Jan 01 23:56:03 a switch is a switch, dammit Jan 01 23:56:18 because one has a LCD and the other OLED, one a c-ts and the other a r-ts, and so on Jan 01 23:57:11 ok, lets assume it is harder to do it for complicated HW like TS and camera, but again - a SWITCH? Jan 01 23:58:05 and even a switch is not like any other. Think of one device having a pushbutton to enable and disable screenlock, while the other device has a slide throwswitch that has a locked and a unlocked position Jan 01 23:58:38 DocScrutinizer05: ever heard of WOSA/XFS? Jan 01 23:58:51 no Jan 01 23:59:04 should I? Jan 01 23:59:14 no, https://en.wikipedia.org/wiki/CEN/XFS Jan 02 00:00:32 freemangordon: now look at what you've done Jan 02 00:00:33 if it is possible to make an unified API to control complicated devices like card readers, cash dispensers and acceptors, etc, I don;t see why the fucjk we cannot have such an api for a swicth (or push button) or whatever you like to call it Jan 02 00:00:43 yeah :) Jan 02 00:02:41 well, as long as you don't upstream your brilliant unified switch API, it is again a proprietary stuff for your very own hw platform only Jan 02 00:03:24 but, it seems it is already upstreamed, according to Pali and is called gpio-key :) Jan 02 00:03:46 hardware people talking about software is almost as bad as software people talking about hardware :< Jan 02 00:03:47 and don't get me wrong, I *cursed* dbus and HAL and friends to hell for their crappy handling of button/switch events Jan 02 00:04:11 but yeah, as SW switch does not fit into that gpio-switch Jan 02 00:04:22 *gpio-key Jan 02 00:04:40 but then you have a way to create stuff in /dev/input Jan 02 00:05:20 kerio: neither me nor DocScrutinizer05 are SW only or HW only guys Jan 02 00:05:39 I also think it's insane that mce has to check GPIO57 or whatever to learn if kbd is open or cam trigger pressed Jan 02 00:06:06 freemangordon: ack :-D Jan 02 00:06:23 exactly. But this is what happens when you make SW with a particular HW platform in mind Jan 02 00:07:53 I really don't get it why power buttons and volume keys produce KBD events, but lock switch and slider do not Jan 02 00:08:03 in stick kernel that is Jan 02 00:08:07 *stock Jan 02 00:08:22 anyway, getting late here , /me going to have some sleep Jan 02 00:08:27 night guys Jan 02 00:09:12 I think if you could use DT or boardfile to devine abstract and speaking (file)names for all MMI elements, this would be outright great. Then I just would miss the config dialog in camera-ui where I can browse the according branch of filesystem tree to define if I want button+/- or button-focus/trigger for the camera, or I go fancy and define switch-kbdslide as camera trigger Jan 02 00:09:27 s/devine/define/ Jan 02 00:09:27 DocScrutinizer05 meant: I think if you could use DT or boardfile to define abstract and speaking (file)names for all MMI elements, this would be outright great. Then I just would miss the config dialog in camera-ui where I can browse the according branch of filesystem tree to de... Jan 02 00:10:27 ...or holdbutton-headset Jan 02 00:11:25 in a way quite similar to what you do in decent programs to define your audio device Jan 02 00:11:49 no, you would not miss that dialog, as you will be able to tell it to use whatever you want from the list of the available input switches in the system Jan 02 00:12:24 anyway, night Jan 02 00:13:11 :-) night! Jan 02 00:13:42 I always thought that /sys/*/bla/GPIO/* approach was pretty kinky Jan 02 00:14:21