| 00:13.50 | *** join/#maemo pozitron (~nu@109.201.143.40) |
| 00:30.19 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 00:38.05 | *** join/#maemo lxp (~lxp@unaffiliated/lxp) |
| 00:46.02 | *** join/#maemo robbiethe1st (~robbiethe@104.235.199.86) |
| 00:49.28 | DocScrutinizer05 | happy new year maemoites |
| 00:51.36 | *** join/#maemo krnlyng (~liar@178.114.16.19.wireless.dyn.drei.com) |
| 01:30.33 | bencoh | s/new/gnu/ |
| 01:32.47 | *** join/#maemo ds3 (~ds2@rehut.com) |
| 01:58.49 | robbiethe1st | Yup |
| 01:59.42 | DocScrutinizer05 | robbiethe1st!! long time no see :-) |
| 01:59.51 | robbiethe1st | I'm still around... ish |
| 01:59.58 | robbiethe1st | If someone highlights me, that is |
| 02:02.07 | robbiethe1st | That being said, I'm still running my N900 and N950. N950's glass cracked a few months back, but still works. And I'm still waiting for something better. |
| 02:19.22 | *** join/#maemo eMHa (~mh@p579DB8A6.dip0.t-ipconnect.de) |
| 02:50.08 | *** join/#maemo Defiant (erik@f050174236.adsl.alicedsl.de) |
| 03:10.02 | *** join/#maemo realitygaps (~realityga@2a01:4a0:3::5096:aeb) |
| 03:10.02 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 04:06.02 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:34.47 | *** join/#maemo trx (ns-team@devbin/founder/trx) |
| 04:57.53 | *** join/#maemo lobito1 (~lobito@190.177.197.164) |
| 05:49.53 | *** join/#maemo Roth (~quassel@2601:18c:c700:c4d3:98d:eafa:320f:320e) |
| 06:36.27 | *** join/#maemo trumee (~trumee@c-50-175-121-86.hsd1.tx.comcast.net) |
| 06:42.12 | *** join/#maemo freemangordon (~ivo@46.249.74.23) |
| 07:02.40 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 07:36.59 | brolin_empey | <PROTECTED> |
| 07:41.06 | kerio | indeed |
| 07:52.42 | brolin_empey | â |
| 07:58.09 | jonwil | is stuck :( |
| 07:59.26 | brolin_empey | is socially isolating himself, as usual. |
| 08:02.55 | brolin_empey | AD MMXVI has arrived in UTC -8 hours. |
| 08:03.32 | brolin_empey | in America/Vancouver . |
| 08:21.04 | KotCzarny | is it 2016 already? i still don't feel any different |
| 08:24.13 | brolin_empey | #include <time.h> |
| 08:26.50 | brolin_empey | sufficientlyadvanced.technology |
| 08:26.58 | brolin_empey | dog.cat |
| 08:27.04 | KotCzarny | yawn(); |
| 08:28.10 | brolin_empey | (MOS)FETish? |
| 08:53.18 | *** join/#maemo qwazix (~qwazix@Maemo/community/ex-council/qwazix) |
| 09:24.00 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:34.35 | *** join/#maemo LauRoman (~LauRoman@5-14-87-59.residential.rdsnet.ro) |
| 09:45.33 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 09:50.06 | *** join/#maemo futpib_ (~futpib@37.113.242.93) |
| 09:59.59 | *** join/#maemo krnlyng (~liar@83.175.90.24) |
| 10:04.01 | *** join/#maemo KotCzarny (ariel@31.135.195.239) |
| 10:04.34 | *** join/#maemo krnlyng (~liar@178.114.16.19.wireless.dyn.drei.com) |
| 10:50.04 | freemangordon | Pali: looks like the bug in isp1704 was present even before transition to usb_phy |
| 10:50.46 | freemangordon | see http://lxr.free-electrons.com/source/include/linux/usb/otg.h?v=3.1#L143 |
| 11:19.54 | Pali | http://lxr.free-electrons.com/source/include/linux/usb/otg.h?v=2.6.36#L142 |
| 11:19.54 | Pali | http://lxr.free-electrons.com/source/include/linux/usb/otg.h?v=2.6.35#L149 |
| 11:19.57 | Pali | freemangordon: ^^^^ |
| 11:20.37 | Pali | this is really stupied they switches signature between 2.6.25 and 2.6.36 |
| 11:20.46 | freemangordon | oh, the change was introduced between 35 and 36 |
| 11:20.52 | freemangordon | ups |
| 11:20.56 | freemangordon | 25 and 36 |
| 11:21.17 | freemangordon | Pali: however, I already sent a patch, you're maintainer there :) |
| 11:21.22 | Pali | yea |
| 11:21.38 | Pali | s/25/35/ |
| 11:21.51 | freemangordon | yep, 35 |
| 11:22.02 | Pali | driver was itroducted in 2.6.37-rc1 |
| 11:22.04 | KotCzarny | huh, changes like that break precompiled blobs usually |
| 11:22.16 | KotCzarny | maybe they do it on purpose sometimes? |
| 11:22.24 | Pali | nope, driver is broken since inclusion |
| 11:22.34 | freemangordon | nah, they simply overslept that |
| 11:22.44 | freemangordon | yes, broken since the inclusion |
| 11:24.51 | freemangordon | Pali: whom else besides you from the n900 guys to cc re rootfs corruption problem? |
| 11:25.04 | freemangordon | pavel? sre? aaro? |
| 11:26.43 | Pali | yes, also tony |
| 11:27.08 | freemangordon | tony is in --to :) |
| 11:27.09 | Pali | and maybe also nishanth |
| 11:27.14 | freemangordon | he is the author |
| 11:27.17 | freemangordon | ah, yes |
| 11:41.29 | *** join/#maemo qwazix (~qwazix@Maemo/community/ex-council/qwazix) |
| 11:48.20 | *** join/#maemo Hurrian (~Hurrian@unaffiliated/rikanee) |
| 11:56.47 | freemangordon | 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 |
| 11:57.06 | freemangordon | *didn't see |
| 11:57.15 | freemangordon | needs moar coffee |
| 11:57.36 | Pali | freemangordon: hm... I do not see any yor new email |
| 11:57.43 | freemangordon | it is not new |
| 11:57.59 | freemangordon | Pali: 25.12.2015 15:36 |
| 11:59.36 | Pali | got it |
| 12:02.04 | Pali | ping sent |
| 12:02.18 | freemangordon | thanks |
| 12:02.37 | Pali | fremangordon, can you resend patch "ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks" as Tomi asked? |
| 12:02.58 | freemangordon | that's what I'm doing :) |
| 12:03.06 | Pali | :-) |
| 12:03.10 | freemangordon | but I need to revert that one and make a new one |
| 12:03.20 | freemangordon | look at the thread |
| 12:05.29 | *** join/#maemo raandoom (~raandoom@83.149.8.188) |
| 12:08.07 | freemangordon | Pali: hmm, looks like it *is* upstreamed |
| 12:09.24 | Pali | why then we still have that patch in linux-n900 and is applied? |
| 12:09.24 | Pali | ? |
| 12:09.36 | freemangordon | no idea |
| 12:11.08 | freemangordon | Pali: see 0eb0dafb674cd6bfac2e3204b2f8b907e26b1138 |
| 12:11.17 | Pali | so question is: what is applied?? |
| 12:11.39 | freemangordon | NFC |
| 12:12.03 | freemangordon | seems what is applied is still correct |
| 12:12.17 | freemangordon | however, I've reverted those 2 patches, going to test |
| 12:17.11 | freemangordon | Pali: or those 2 are the reason for non-working backlight fade, will see in a minute |
| 12:17.26 | Pali | test |
| 12:17.33 | freemangordon | at least it still boots |
| 12:17.38 | freemangordon | to h-d that is |
| 12:20.41 | freemangordon | Pali: well, backlight fade still does not work, but it boots, so those 2 patches seem to be not needed |
| 12:20.59 | Pali | ok |
| 12:26.17 | freemangordon | Pali: ok, what now? |
| 12:26.35 | Pali | need to figure out what that patch is doing :-) |
| 12:26.45 | freemangordon | which one? |
| 12:33.28 | Pali | those two in linux-n900 tree... |
| 12:33.58 | freemangordon | maybe nothing, they patch files no longer needed |
| 12:34.11 | freemangordon | but ok, do it |
| 12:40.03 | *** join/#maemo Hurrian (~Hurrian@unaffiliated/rikanee) |
| 12:51.11 | *** join/#maemo FlameReaper-PC (~FR@175.139.21.117) |
| 13:11.51 | freemangordon | Pali: who was monitoring the slide gpio? |
| 13:12.07 | Pali | mce |
| 13:12.14 | freemangordon | hmm |
| 13:13.17 | Pali | and hald-addon-omap-gpio |
| 13:22.10 | freemangordon | Pali: we can bindmount in /sys :) |
| 13:22.39 | Pali | and, how you create dynamic content with poll support? |
| 13:22.50 | freemangordon | no idea :) |
| 13:22.56 | Pali | rather fixing mce other libs to use new api |
| 13:23.01 | Pali | which is in upstream kernel |
| 13:23.08 | freemangordon | well, ok |
| 13:23.13 | Pali | and for sscd create LD_PRELOAD library |
| 13:23.40 | Pali | or check if sscd really needs to touch gpio... (if configuring externally is not enough) |
| 13:28.57 | KotCzarny | funny thing those rdepends: http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/mc/4.8.14-0maemo1/ |
| 13:29.45 | *** join/#maemo smhar (~salman@178.132.44.178) |
| 13:32.52 | *** join/#maemo realitygaps (~realityga@2a01:4a0:3::5096:aeb) |
| 13:32.52 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 14:03.08 | *** join/#maemo pcfe (~pcfe@2a02:8109:8080:fa4:beee:7bff:fed9:8f1b) |
| 14:03.11 | *** join/#maemo pcfe (~pcfe@redhat/pcfe) |
| 14:32.55 | *** join/#maemo xorly (~xorly@ip-86-49-15-121.net.upcbroadband.cz) |
| 14:38.49 | *** join/#maemo Hurrian (~Hurrian@unaffiliated/rikanee) |
| 14:53.52 | Pali | KotCzarny: because of provides |
| 15:00.48 | *** join/#maemo chfoo (~chris@UNVLON5554W-LP130-03-1242507898.dsl.bell.ca) |
| 15:04.45 | *** join/#maemo Hurrian (~Hurrian@unaffiliated/rikanee) |
| 15:27.33 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 16:10.32 | *** join/#maemo protem (~protem@unaffiliated/protem) |
| 16:21.52 | *** join/#maemo realitygaps (~realityga@2a01:4a0:3::5096:aeb) |
| 16:21.52 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 16:50.49 | *** join/#maemo sq-one (~sq-one@HSI-KBW-5-56-236-246.hsi17.kabel-badenwuerttemberg.de) |
| 16:51.52 | KotCzarny | pali: i find it quite hilarious that mc is a dependency for qml-browser etc |
| 16:56.14 | Pali | mc provides mcedit which is able to view text files |
| 16:56.43 | Pali | and some of those qml-browser dependency packages depends on something which nees to view text files |
| 16:57.14 | *** join/#maemo erlehmann_ (~erlehmann@ovpn-212-148.vpn.hu-berlin.de) |
| 16:57.15 | Pali | and so you mc via mcedit is one of alternatives for that dependency |
| 16:57.48 | KotCzarny | so its not a 'required' but might be 'suggested' ? |
| 16:58.32 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 16:59.57 | *** part/#maemo erlehmann (~erlehmann@ovpn-212-148.vpn.hu-berlin.de) |
| 17:03.20 | Sicelo | i once had qml-browser on both my N900, but it never pulled mc. that's "new" dependency? |
| 17:04.24 | KotCzarny | sicelo, it might showed in 'suggested' |
| 17:04.28 | KotCzarny | or 'recommended' |
| 17:04.36 | KotCzarny | 've |
| 17:07.13 | *** join/#maemo Gadgetoid (~Gadgetoid@customers.shef1.resi.ask4.co.uk) |
| 17:17.32 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 17:33.14 | DocScrutinizer05 | md ~/c3torrents; for x in `wget -q -O- http://cdn.media.ccc.de/congress/2015/h264-hd/ | grep '\.mp4'|sed 's/.*<a href="//' |sed 's/">.*//'`; do wget -q -P ~/c3torrents -c http://cdn.media.ccc.de/congress/2015/h264-hd/$x.torrent; done |
| 17:42.36 | *** join/#maemo ssvb (~ssvb@dsl-espbrasgw1-50dce4-232.dhcp.inet.fi) |
| 17:55.40 | *** join/#maemo ssvb (~ssvb@dsl-espbrasgw1-50dce4-232.dhcp.inet.fi) |
| 18:08.02 | *** join/#maemo sparetire_ (~sparetire@unaffiliated/sparetire) |
| 18:17.12 | *** join/#maemo ssvb (~ssvb@85-76-136-87-nat.elisa-mobile.fi) |
| 18:37.45 | freemangordon | Pali: and what is the problem with gpio-switch driver? |
| 18:38.30 | freemangordon | 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 |
| 18:44.03 | *** part/#maemo ludens (~user@gateway/vpn/privateinternetaccess/ludens) |
| 18:48.04 | Pali | freemangordon: because it does not work :-) |
| 18:48.20 | freemangordon | any idea why it does not work? |
| 18:48.21 | Pali | it just export static data so mce and other stuff does not crash |
| 18:48.34 | Pali | because only one driver can use gpios |
| 18:48.34 | freemangordon | I know, but why not make it wokring? |
| 18:49.01 | Pali | you cannot make it working without rewriting linux kernel module subsystem |
| 18:49.02 | freemangordon | ok, and who uses slide, cam_focus, etc? |
| 18:49.26 | Pali | other drivers, gpio event input |
| 18:49.27 | Pali | ... |
| 18:49.49 | freemangordon | Pali: there is gpiod_export_link |
| 18:50.10 | Pali | which export them to /sys/class/gpio/<num>/ |
| 18:50.24 | freemangordon | no, ^^^ export it in your driver dir |
| 18:50.51 | freemangordon | or wherever you make symlink to point to |
| 18:51.11 | freemangordon | Pali: see http://lxr.free-electrons.com/source/drivers/gpio/gpiolib-sysfs.c#L638 |
| 18:51.43 | Pali | so it just create symlink |
| 18:51.59 | freemangordon | yes |
| 18:52.05 | Pali | thats now enough |
| 18:52.11 | freemangordon | I know |
| 18:52.11 | Pali | see format of gpio-switch |
| 18:52.15 | freemangordon | yes |
| 18:52.35 | Pali | gpiod_export_link is useless here... |
| 18:52.43 | Pali | I do not see any advantages for it |
| 18:53.47 | freemangordon | Pali: the other option is to create (daemon, driver) that bindmounts what is needed by maemo while doing poll() |
| 18:54.13 | freemangordon | isn;t it possible to use fuse or somesuch? |
| 18:54.19 | Pali | how do you want to simulate poll() |
| 18:54.20 | Pali | ? |
| 18:54.39 | Pali | err.. how do you want to check if application is doing poll()? |
| 18:54.41 | freemangordon | only divers can do it? |
| 18:55.09 | Pali | all this is just more work as rewriting existing code to use new api |
| 18:55.41 | freemangordon | and all the code that needs to be rewritten is foss? |
| 18:55.57 | freemangordon | also, keep in mind we should keep backwards compatibility as well |
| 18:56.04 | Pali | except sscd... yes |
| 18:56.21 | Pali | rather create LD_PRELOAD lib |
| 18:56.35 | freemangordon | hmm |
| 18:56.40 | Pali | this should be easier |
| 18:56.53 | freemangordon | then there is no need to fix mce, hal, etc |
| 18:57.07 | freemangordon | if we're going to LD_PRELOAD |
| 18:57.20 | Pali | rather use LD_PRELOAD just for sscd |
| 18:57.26 | Pali | and fix other stuff |
| 18:57.32 | freemangordon | but I still think LD_PRELOAD is very nasty hack |
| 18:57.47 | Pali | yes, reason why only for sscd |
| 18:58.36 | freemangordon | Pali: well, I'll check if there is a way to create poll()-able files from userspace |
| 18:58.48 | Pali | no |
| 18:58.56 | Pali | you cannot do that |
| 19:00.53 | freemangordon | Pali: what about ptty? |
| 19:01.28 | Pali | ehm... all this sounds like worse hack as LD_PRELOAD |
| 19:01.34 | freemangordon | or it is char device? |
| 19:01.46 | Pali | it is char device |
| 19:02.08 | freemangordon | won;t work then |
| 19:02.12 | Pali | anyway, if you create such thing somehow, you have one big problem |
| 19:02.21 | Pali | you cannot call mkdir in sysfs |
| 19:02.23 | freemangordon | which is? |
| 19:02.26 | Pali | on which you do mount --bind |
| 19:02.39 | freemangordon | gpio-switch doe it for me already |
| 19:02.44 | freemangordon | *does |
| 19:02.52 | Pali | so you still need kernel changes for it |
| 19:03.09 | freemangordon | sure |
| 19:03.27 | Pali | sounds bad |
| 19:03.36 | freemangordon | but this is just a small driver we have to support out of the tree |
| 19:03.50 | Pali | too much work |
| 19:03.57 | Pali | and no idea if it works correctly |
| 19:04.09 | Pali | really it is easier to patch existing applications |
| 19:04.27 | Pali | and for sscd check if it really needs to use gpio |
| 19:04.49 | Pali | e.g. if external daemon for configuring cmt gpio is not enough |
| 19:05.06 | Pali | and if not, LD_PRELOAD for sscd |
| 19:13.47 | *** join/#maemo ssvb (~ssvb@dsl-espbrasgw1-54f9c5-175.dhcp.inet.fi) |
| 19:23.37 | *** join/#maemo louisdk (~louisdk@static-5-103-130-65.seas-nve.net) |
| 19:29.02 | freemangordon | Pali: could fuse do the job? |
| 19:29.21 | Pali | yes... |
| 19:29.41 | Pali | ... but this is even worse as all above .... |
| 19:29.49 | freemangordon | isn;t that upstreamed? |
| 19:29.53 | freemangordon | fuse I mean |
| 19:30.32 | freemangordon | seems like no |
| 19:30.38 | Pali | fuse is in upstream... |
| 19:30.49 | freemangordon | oh, great then |
| 19:30.51 | Pali | but this is really stupid... |
| 19:30.55 | Pali | and also harder |
| 19:30.56 | freemangordon | why? |
| 19:31.05 | Pali | because it does not solve original problem |
| 19:31.12 | Pali | just add another layer of other problems |
| 19:31.15 | Pali | related to fuse |
| 19:31.37 | freemangordon | we'll just need to implement gpio-swith by using fuse, ain;t? |
| 19:31.48 | Pali | I really want to avoid all those layers and hacks... |
| 19:32.52 | freemangordon | 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? |
| 19:32.55 | Wizzup | Brewster had daar geen problemen mee |
| 19:32.59 | Wizzup | oops. darmn. sorry. |
| 19:33.01 | Wizzup | wrong channel. |
| 19:33.32 | freemangordon | Pali: we should somehow split mce from the HW |
| 19:33.39 | freemangordon | mce and the others |
| 19:33.47 | Pali | split? |
| 19:34.13 | freemangordon | ok, make some kind of "impedance matcher" between mce and the HW |
| 19:34.39 | freemangordon | what if your camera "button" is not a HW switch, but soft button? |
| 19:34.49 | freemangordon | do you get me? |
| 19:35.07 | freemangordon | we simply cannot hack mce for every possible HW config |
| 19:35.21 | freemangordon | thus we need some layer to translate |
| 19:35.27 | Pali | do not know... |
| 19:37.28 | freemangordon | 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 |
| 19:38.00 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 19:40.22 | freemangordon | 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 |
| 19:41.00 | freemangordon | your userspace simply have no way to find which is the correct gpio to use |
| 19:41.58 | freemangordon | the other option is to extend the kernel interface gpio export functionality, to attach some meningful "name" to the exported gpio |
| 19:42.18 | freemangordon | instead of that cryptic gpioN |
| 19:42.40 | freemangordon | Pali: what do you think? ^^^ |
| 20:01.41 | ceene | i'm not up to date with your discussion on this, guys, so forgive me if I propose somehing stupid |
| 20:01.59 | ceene | but the standard way wouldn't be to prove /dev/input devices? |
| 20:02.21 | ceene | those could use gpio driver but provide a common interface to user space |
| 20:04.04 | *** join/#maemo realitygaps (~realityga@2a01:4a0:3::5096:aeb) |
| 20:04.04 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 20:04.22 | freemangordon | ceene: gpio could be output as well |
| 20:05.04 | *** join/#maemo louis_ (~louisdk@static-5-103-130-65.seas-nve.net) |
| 20:05.18 | freemangordon | and there *is* a standard interface in /sys, just not smart enough IMO |
| 20:05.22 | *** join/#maemo ssvb (~ssvb@dsl-espbrasgw1-54f9c5-175.dhcp.inet.fi) |
| 20:06.06 | freemangordon | 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 |
| 20:06.46 | freemangordon | this should be easily doable, struct gpio_desc already has a member called "label" |
| 20:08.34 | *** join/#maemo lopng (~ircchatte@109.240.240.211) |
| 20:23.54 | DocScrutinizer05 | ((make some kind of "impedance matcher" between mce and the HW)) that's called HardwareAbstractionLayer |
| 20:25.55 | DocScrutinizer05 | ((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 |
| 20:26.41 | DocScrutinizer05 | or even flasher does, and chooses the right version of firmware to flash to device |
| 20:26.55 | DocScrutinizer05 | see N900 ;-) |
| 20:27.22 | DocScrutinizer05 | there's a version that swaps blue and red (iirc) LED of LP5523 indicator light |
| 20:27.42 | DocScrutinizer05 | check lp5523.ko sources, I think it's in there |
| 20:34.01 | freemangordon | 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 |
| 20:34.09 | freemangordon | the same goes for gpios |
| 20:41.13 | *** join/#maemo ssvb (~ssvb@dsl-espbrasgw1-54f9c5-175.dhcp.inet.fi) |
| 20:57.02 | *** join/#maemo ssvb_ (~ssvb@dsl-espbrasgw1-54f9c5-175.dhcp.inet.fi) |
| 20:58.22 | *** join/#maemo krnlyng (~liar@77.117.2.254.wireless.dyn.drei.com) |
| 21:00.44 | Pali | freemangordon: those events are export by other drivers, like input driver, etc |
| 21:01.14 | Pali | input kernel subsystem has for this purpose special "switch" events |
| 21:01.24 | Pali | which perfectly match this needs |
| 21:01.33 | Pali | and they are already in upstream for n900! |
| 21:34.33 | jonwil | it seems like it would be helpful to document everything on the system that touches /sys/* |
| 21:34.58 | jonwil | oh wait I think I did that before |
| 21:38.57 | jonwil | or not |
| 21:43.28 | Pali | wiki.maemo.org --> Porting --> Kernel |
| 21:44.13 | jonwil | yeah thats a great start, this one will be more comprehensive though :P |
| 21:46.00 | freemangordon | Pali: who exports "slide"? |
| 21:50.29 | Pali | freemangordon: input |
| 21:50.40 | freemangordon | Pali: see, if there is an existing driver classes for all the various switches and sensors on n900, I am fine with reusing them |
| 21:51.03 | Pali | freemangordon: should be |
| 21:51.15 | Pali | because other kernel drivers uses those GPIOs already |
| 21:51.21 | freemangordon | hmm, ok |
| 21:51.23 | Pali | exception is CMT part |
| 21:51.36 | freemangordon | CMT should be fine, as it is Nokia specific |
| 21:51.48 | Pali | but there is nokia-modem.pm=1 (export via /sys/class/gpio/) you knwo |
| 21:51.49 | Pali | *know |
| 21:51.53 | freemangordon | yeah |
| 21:54.15 | freemangordon | boots 4.4 to see where in /sys/class/input is exported "slide" |
| 21:55.19 | Pali | freemangordon: no /dev/input/event* |
| 21:55.43 | freemangordon | so, we should create a driver to export it? |
| 21:55.56 | freemangordon | soory for the maybe stupid questions |
| 21:56.01 | freemangordon | *sorry |
| 21:56.24 | Pali | you need to use /dev/input for it |
| 21:56.35 | Pali | but now going to look into source code |
| 22:02.53 | *** join/#maemo justingo (~csernelha@563BB0F6.dsl.pool.telekom.hu) |
| 22:04.10 | *** join/#maemo justingo (~csernelha@563BB0F6.dsl.pool.telekom.hu) |
| 22:05.40 | *** join/#maemo justingo (~csernelha@563BB0F6.dsl.pool.telekom.hu) |
| 22:07.14 | Pali | freemangordon: you need to compile gpio-keys.ko |
| 22:07.25 | Pali | and then via /dev/input/event<num> ask for switch status |
| 22:08.00 | Pali | currently gpio-keys.ko is disabled in linux-n900 tree CONFIG_KEYBOARD_GPIO=m is needed for it |
| 22:11.12 | freemangordon | Pali: and how do you distinguish between various switch types? is there interface for it? |
| 22:11.39 | freemangordon | Pali: and what "ask" means? poll()? |
| 22:11.39 | Pali | freemangordon: yes, each switch has its own "code" |
| 22:11.46 | freemangordon | code? |
| 22:11.53 | Pali | like key press |
| 22:12.04 | Pali | every key has its own code |
| 22:12.54 | Pali | keypad_slide --> gpios = <&gpio3 7 GPIO_ACTIVE_LOW>; /* 71 */ --> linux,code = <0x0a>; /* SW_KEYPAD_SLIDE */ |
| 22:13.00 | Pali | all is defined in DTS |
| 22:13.03 | freemangordon | oh, so we open all the stuff in /dev/input and wait for KEY_SLIDE on all of the descriptors? |
| 22:13.17 | Pali | not all stuff in /dev/input |
| 22:13.33 | Pali | just one device which has that name gpio-keys |
| 22:14.10 | freemangordon | where is that "name" defined? in /sys/input/devices? |
| 22:15.19 | *** join/#maemo justingo (~csernelha@563BB0F6.dsl.pool.telekom.hu) |
| 22:21.57 | jonwil | Pali: Is the intent that upstream kernel works with stock bme or will upstream kernel need your bme replacement? |
| 22:23.43 | jonwil | actually, it doesn't matter :) |
| 22:23.50 | freemangordon | jonwil: it needs bme-replacement |
| 22:23.53 | jonwil | ok |
| 22:26.16 | jon_y | are we getting kernel 4.x yet? :) |
| 22:27.56 | Pali | freemangordon: name is defined in DTS too |
| 22:28.19 | Pali | jonwil: upstream kernel works with bme replacment |
| 22:28.30 | Pali | *already* |
| 22:42.50 | *** join/#maemo robink_ (~quassel@unaffilated/robink) |
| 22:50.41 | *** join/#maemo realitygaps (~realityga@2a01:4a0:3::5096:aeb) |
| 22:50.41 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 23:03.47 | DocScrutinizer05 | 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 |
| 23:04.15 | Wizzup | having an upstream kernel is great for many reasons |
| 23:04.40 | Wizzup | for one - grsecurity :) |
| 23:05.02 | DocScrutinizer05 | well, having an upstream jkernel doesn't mean you need *all* of that stuff, most is cruft for your particular device |
| 23:05.37 | Wizzup | 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 :) |
| 23:05.54 | Wizzup | Either way, I'm happy with the work that seems to be done! |
| 23:06.00 | *** join/#maemo erlehmann (~erlehmann@141.20.212.148) |
| 23:06.10 | DocScrutinizer05 | because such generic stuff costs storage and memory and runtime |
| 23:07.40 | DocScrutinizer05 | 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 |
| 23:08.27 | DocScrutinizer05 | but I don't want to argue, I know I won't make a point against 99% of devels |
| 23:09.59 | DocScrutinizer05 | 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 |
| 23:10.15 | Wizzup | which is dreadful for security and interoperability |
| 23:10.36 | Wizzup | I don't think some generic path resolve will use that much mem/storage/runtimecpu |
| 23:10.39 | DocScrutinizer05 | err why? as long as upstream patches apply to your local branch? |
| 23:10.52 | Wizzup | because it is a PITA to maintain |
| 23:11.02 | jonwil | Pali: Do we have a list somewhere of all interfaces under /sys and /proc that have changed between N900 stock kernel and upstream kernel? |
| 23:11.04 | Wizzup | keeping track of all the security patches, let alone bug fixes |
| 23:11.09 | Wizzup | jonwil: he left |
| 23:11.13 | jonwil | oh ok |
| 23:11.27 | DocScrutinizer05 | tzz, that's the "I'm too lazy" argument that naver resulted in technically optimized solutions |
| 23:11.27 | Wizzup | jonwil: maybe the wiki article he mentioned helps (I guess you saw it already) |
| 23:11.43 | jonwil | nope, that doesn't help so much |
| 23:13.12 | DocScrutinizer05 | as long as you do smart 'proprietary' patches to your branch, upstream security and maintenance patches should apply without any conflict |
| 23:13.48 | Wizzup | but why bother if you can just use the latest version? why spend many hours on something that is already taken care of |
| 23:13.54 | Wizzup | anyway, I also don't want to argue :) |
| 23:16.19 | DocScrutinizer05 | because of the headache freemangordon has with "what do we do with changing/differing GPIO numbers on same platform" |
| 23:16.41 | DocScrutinizer05 | for example |
| 23:17.38 | DocScrutinizer05 | embedded is *way* more different from platform to platform than your average PC differs between Dell and younameit |
| 23:18.16 | DocScrutinizer05 | 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 |
| 23:18.19 | kerio | my embedded ARM home server runs mainline linux |
| 23:18.51 | Wizzup | kerio: mine too :) |
| 23:18.59 | Wizzup | my arm laptop too |
| 23:19.02 | kerio | and it's awful |
| 23:19.06 | kerio | because it's not bsd |
| 23:19.10 | Wizzup | lol. |
| 23:19.19 | DocScrutinizer05 | kerio: then prolly because some poor sods upstreamed the patches needed to make the linux run on that platform |
| 23:19.29 | kerio | indeed! |
| 23:19.40 | kerio | maemo has *two* poor sods |
| 23:19.41 | Wizzup | DocScrutinizer05: what's with the hate? Why isn't it awesome that we can use stuff like btrfs on ARM home servers? |
| 23:19.56 | DocScrutinizer05 | huh? |
| 23:19.59 | Wizzup | Some things takes so much work to backport to older versions, when you can simple use the latest LTS / mainline version |
| 23:20.03 | DocScrutinizer05 | you totally lost me |
| 23:20.08 | Wizzup | poor sods -> great people |
| 23:20.11 | Wizzup | :) |
| 23:20.14 | Wizzup | is my point mostly |
| 23:20.18 | Wizzup | guess I misunderstood |
| 23:20.33 | kerio | DocScrutinizer05: being able to run mainline means that you get access to new features |
| 23:20.39 | kerio | and they can be good |
| 23:20.46 | DocScrutinizer05 | so what? |
| 23:21.28 | Wizzup | That can often means better performance, lower memory usage, more bug fixes, etc, etc. |
| 23:21.40 | Wizzup | Better crypto, other things relevant to embedded |
| 23:22.26 | DocScrutinizer05 | 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 |
| 23:22.48 | Wizzup | I still do that for all my machines |
| 23:22.55 | Wizzup | And you can also do that for the N900 with mainline/upstream |
| 23:22.58 | kerio | DocScrutinizer05: that's not at all what "mainline kernel" means |
| 23:23.05 | kerio | or, rather |
| 23:23.13 | kerio | that's not in contradiction with |
| 23:24.19 | DocScrutinizer05 | 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 |
| 23:24.40 | Wizzup | there are quite some arm devices where everything is upstreamed :) |
| 23:24.51 | DocScrutinizer05 | and you might want to prune that branch to kick out obviously cruft items |
| 23:25.04 | Wizzup | I think for the n900, where the bits are not upstreamed, they are in some branch. Like with amd64 platform drivers |
| 23:25.06 | DocScrutinizer05 | ARM doesn't need PCI-support |
| 23:25.40 | DocScrutinizer05 | nor fan sensor support |
| 23:25.54 | DocScrutinizer05 | nor weird AMD graka drivers |
| 23:26.09 | Wizzup | Jetson TK1 has PCI slots |
| 23:26.15 | Wizzup | TX1 has them too |
| 23:26.24 | Wizzup | and the ARM servers have them too |
| 23:26.28 | kerio | :o |
| 23:26.30 | DocScrutinizer05 | N900 has _not_ exactly my point |
| 23:26.36 | Wizzup | You said "ARM" :) |
| 23:26.42 | kerio | neo900 feature request: pci express |
| 23:26.45 | DocScrutinizer05 | :-P |
| 23:26.54 | Wizzup | merlijn@deepwater ~ $ sudo zgrep CONFIG_PCI /proc/config.gz |
| 23:26.54 | Wizzup | # CONFIG_PCI is not set |
| 23:27.00 | Wizzup | ^arm machine |
| 23:27.02 | Wizzup | not hard to disable :) |
| 23:27.52 | DocScrutinizer05 | ok, and what do you do when it starts to be hard or impossible? |
| 23:28.08 | kerio | you file a bug |
| 23:28.14 | kerio | it's linux, not systemd |
| 23:28.29 | Wizzup | gnu/linux in the case of the n900 |
| 23:28.32 | Wizzup | hides |
| 23:28.36 | DocScrutinizer05 | like with lis302 driver which is completely brainfucked in upstream, and will cut through your battery in no time |
| 23:28.37 | kerio | the maintainer yells at the other devs, not at the users |
| 23:28.59 | kerio | Wizzup: no, "linux" is quite specifically correct here |
| 23:29.06 | Wizzup | kerio: I realised ;-) |
| 23:29.08 | Wizzup | I just felt trolly |
| 23:29.12 | Wizzup | I'll go and hit the sack :) |
| 23:31.05 | *** join/#maemo lobito (~lobito@190.177.197.164) |
| 23:44.07 | freemangordon | DocScrutinizer05: reasons are technical, I give a shit about politics and you know it :) |
| 23:45.49 | freemangordon | very similar to what Wizzup said - the cost of maintenance and platform independence |
| 23:47.16 | freemangordon | why we should have HW specific stuff if we can skip it |
| 23:48.48 | freemangordon | 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 |
| 23:49.41 | freemangordon | or what Pali said ^^^ - using generic /dev/input interface with board file providing the HW specific settings |
| 23:50.28 | freemangordon | DocScrutinizer05: also, believe it or not, but upstream kernel runs waaay faster that stock, when it works ofc |
| 23:51.08 | freemangordon | we have things like neon-optimized functions, RCU, lots of optimizations, etc, etc |
| 23:52.06 | freemangordon | I am not thinking N900 or Neo900 here, but Maemo |
| 23:52.36 | freemangordon | from the POV of the userspace it should not matter what platform it is and whether it is embedded or server |
| 23:54.31 | freemangordon | 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 |
| 23:54.44 | DocScrutinizer05 | 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 |
| 23:55.38 | freemangordon | 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 |
| 23:55.44 | DocScrutinizer05 | you can't expect same kernel API on different platforms |
| 23:55.47 | *** join/#maemo esaym (~esaym153@75.1.182.8) |
| 23:55.52 | freemangordon | why? |
| 23:56.03 | freemangordon | a switch is a switch, dammit |
| 23:56.18 | DocScrutinizer05 | because one has a LCD and the other OLED, one a c-ts and the other a r-ts, and so on |
| 23:56.48 | *** join/#maemo heroux_ (sandroco@gateway/shell/insomnia247/x-sgfkwvrdalhtwunb) |
| 23:56.49 | *** join/#maemo keithzg_ (~quassel@198-48-129-100.cpe.pppoe.ca) |
| 23:57.11 | freemangordon | ok, lets assume it is harder to do it for complicated HW like TS and camera, but again - a SWITCH? |
| 23:57.55 | *** join/#maemo luke-jr_ (~luke-jr@unaffiliated/luke-jr) |
| 23:58.05 | DocScrutinizer05 | 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 |
| 23:58.38 | freemangordon | DocScrutinizer05: ever heard of WOSA/XFS? |
| 23:58.51 | DocScrutinizer05 | no |
| 23:59.04 | DocScrutinizer05 | should I? |
| 23:59.15 | freemangordon | no, https://en.wikipedia.org/wiki/CEN/XFS |