| 00:02.31 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-taiacfhkjaftcjrv) |
| 00:03.44 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 00:31.42 | *** join/#oe gabrbedd (~beddingfi@li680-65.members.linode.com) |
| 02:39.49 | *** join/#oe infobot (ibot@208.53.50.136) |
| 02:39.49 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 02:41.52 | *** join/#oe comptroller (~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net) |
| 03:31.10 | khem | Crofton: he has a point but too soon. The real fix is here https://github.com/meta-qt5/meta-qt5/pull/127 |
| 04:45.37 | *** join/#oe mario-goulart (~user@static.107.70.9.5.clients.your-server.de) |
| 05:48.49 | *** join/#oe Darkmatter66 (~Darkmatte@37.237.210.37) |
| 06:31.07 | *** join/#oe Jybz (~jibz@2a02:8071:9289:5900:4a51:b7ff:fe84:99e6) |
| 06:37.39 | *** join/#oe armpit (~armpit@97-121-174-158.clsp.qwest.net) |
| 06:49.19 | *** join/#oe yegorich (~yegorich@mail.visionsystems.de) |
| 07:09.32 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 07:11.19 | *** join/#oe Darkmatter66_ (~Darkmatte@37.237.210.222) |
| 07:22.00 | *** join/#oe Bunio_FH (~bunio@81-18-201-214.static.chello.pl) |
| 07:24.58 | *** join/#oe frsc (~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d) |
| 07:35.47 | *** join/#oe lusus (~lusus@62.91.23.180) |
| 07:38.35 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 08:17.27 | *** join/#oe ao2 (~ao2@87.19.23.4) |
| 08:31.11 | *** join/#oe Darkmatter66 (~Darkmatte@37.237.210.230) |
| 08:41.09 | *** join/#oe Darkmatter66 (~Darkmatte@37.237.210.230) |
| 08:49.19 | *** join/#oe waterscale (~waterscal@77.41.145.142) |
| 08:49.39 | *** join/#oe Darkmatter66 (~Darkmatte@37.237.210.45) |
| 08:53.17 | waterscale | hi. could somebody help me understand how do gpio pins within linux correspond to the actual gpio pins on my module? i have gpiochip0, gpiochip32 [...] gpiochip128 in /sys/class/gpio/, so sysfs gpio support seems to be there |
| 08:54.24 | waterscale | and there's a comprehensive hardware manual for the module, i just can't understand how do i transform something like "GPIO1_3" to linux gpio number |
| 08:57.33 | LetoThe2nd | waterscale: i think this is a pretty neat explanation: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842398/Linux+GPIO+Driver#LinuxGPIODriver-UsingtheGPIODriverfromaUserSpaceApplication |
| 08:58.37 | LetoThe2nd | ah no sorry, wrong paragraph. see https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842398/Linux+GPIO+Driver#LinuxGPIODriver-UsingGPIOwithSysFs |
| 08:59.34 | LetoThe2nd | also see the linked https://lkml.org/lkml/2014/7/7/390 |
| 08:59.47 | LetoThe2nd | in a nutshell: it depends a bit on the specific SoC in use |
| 09:00.46 | waterscale | LetoThe2nd: "it depends" was the answer i feared most lol. thanks for the links, gonna try those |
| 09:01.49 | LetoThe2nd | waterscale: i can only tell you (IIRC) what applies for my HW (atmel sama5d3): its gpio bank * 32 + pin number, so for gpio1_3 it would be "3". echoing that into export does the trick |
| 09:02.59 | waterscale | that's the bruteforce approach i'm keeping for later :) |
| 09:03.33 | LetoThe2nd | why? |
| 09:04.36 | waterscale | it's not urgent, i'd rather try to understand the underlying concept first, and then after i fail in a couple hours i'll resolve to trying to guess the correct gpio |
| 09:04.46 | waterscale | it's a neverending cycle |
| 09:05.59 | LetoThe2nd | no, i mean, its not a bruteforce approach. its the usual process to use a gpio. you echo something into export to get access to the pin |
| 09:07.13 | *** join/#oe tprrt (~tprrt@217.114.201.133) |
| 09:07.57 | *** join/#oe AndersD (~AndersD@h83-209-191-235.cust.a3fiber.se) |
| 09:09.44 | *** join/#oe AndersD_ (~AndersD@194.237.220.218) |
| 09:14.27 | waterscale | that much i understand, i just don't get how it actually maps within the system yet. gpiochip{0,32,64,96,128}/label gives me something that's probably directly out of the device tree, stuff like "209c000.gpio" |
| 09:15.12 | LetoThe2nd | waterscale: if you look into the gpiochip directories, then at label, you pretty much get exactly the mmio address. |
| 10:00.10 | *** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa) |
| 10:37.50 | *** join/#oe ant_work (~ant__@87.13.122.174) |
| 10:38.20 | *** join/#oe lusus (~lusus@62.91.23.180) |
| 10:41.30 | *** join/#oe berton (~berton@181.220.65.91) |
| 10:47.19 | *** join/#oe berton (~berton@181.220.65.91) |
| 10:51.18 | ant_work | koen, hi |
| 10:51.29 | ant_work | I asked long ago about meta-kodi |
| 10:52.05 | ant_work | do you know about issues with mips in the last kodi versions? |
| 11:12.15 | ant_work | btw I see p8platform: update to 2.1.0.1 in meta-oe |
| 11:14.11 | *** join/#oe maelcum (~horst@200116b842871700a9fa0f912707126a.dip.versatel-1u1.de) |
| 12:38.50 | koen | ant_work: haven't tried it on mips, only aarch64 and x86_64 |
| 12:54.15 | *** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa) |
| 13:15.17 | *** join/#oe stefan_schmidt (~stefan_sc@p200300E9D7278E71637C643A5A746A69.dip0.t-ipconnect.de) |
| 13:43.34 | ant_work | koen, ok, I will just try with qemumips |
| 13:44.40 | ant_work | it is for the STB vuplus duo2, I think there might be issues with the gles driver |
| 13:45.22 | ant_work | that crazy dutch people at OpenPLi have an unfinished 17.6 |
| 13:45.59 | ant_work | (they are now rebasing to rocko) |
| 14:31.44 | *** join/#oe JPEW (cc4da337@gateway/web/freenode/ip.204.77.163.55) |
| 15:32.57 | *** join/#oe infobot (ibot@208.53.50.136) |
| 15:32.57 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 15:54.50 | *** join/#oe feddischson (~feddischs@55d49ffa.access.ecotel.net) |
| 16:05.06 | *** join/#oe JaMa (~martin@217.30.68.212) |
| 16:09.42 | *** join/#oe dqx_ (~dqx@unaffiliated/dqx) |
| 16:54.34 | *** join/#oe rburton_ (~rburton@35.106.2.81.in-addr.arpa) |
| 16:58.50 | *** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa) |
| 17:42.29 | *** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com) |
| 17:53.55 | *** join/#oe cristiano (~cris@pdpc/supporter/active/cristiano) |
| 18:02.36 | *** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com) |
| 18:06.21 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 18:18.24 | *** join/#oe stefan_schmidt (~stefan_sc@p200300E9D732AFED80749B0151FE7799.dip0.t-ipconnect.de) |
| 18:32.34 | *** join/#oe berton_ (~berton@181.220.65.91) |
| 18:37.38 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 18:39.30 | *** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa) |
| 18:40.09 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 18:40.37 | JaMa | khem: I've fixed known_hosts on abaco to rsync to milla, will see after the build is finished if it works now |
| 18:40.45 | JaMa | halstead: ^ |
| 18:42.41 | halstead | JaMa, Sounds good. I was reading over that thread earlier today. This is the next logical fix. |
| 18:43.05 | JaMa | halstead: what was the other fix? |
| 18:45.59 | khem | JaMa: thx |
| 18:46.50 | *** join/#oe dv_ (~dv@62-178-50-190.cable.dynamic.surfer.at) |
| 18:52.21 | JaMa | khem: are you using rpi3 for something serious? I have seen a lot of interesting patches from you to meta-raspberrypi recently |
| 19:06.30 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:11.28 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 19:20.00 | khem | JaMa: yes |
| 19:21.05 | khem | This is default reference for RDK now |
| 19:21.56 | *** join/#oe dqx (~dqx@unaffiliated/dqx) |
| 19:30.13 | JaMa | khem: aarch64 as well were you using vc4graphics for arm? |
| 19:31.42 | JaMa | khem: I'm asking because with webOS OSE we have strange combination, 32bit arm + vc4graphics + userland (without egl, removed with patch, but otherwise similar to your new userland-nogl) for multimedia |
| 19:32.34 | *** join/#oe georgem (~georgem@216.21.169.52) |
| 19:32.53 | JaMa | khem: this combo doesn't work well with newer kernels (so I'm tempted to drop vc4graphics completely, which leads to some issues with qtbase) and for aarch64 our media guys didn't figure out how to replace userland binaries at all |
| 19:33.34 | khem | JaMa: vc4graphics is the way to go and not drop it |
| 19:34.08 | khem | eventually we want everything to work well with mesa/vc4graphics |
| 19:34.53 | khem | we are optimizing RDK wayland compositor (westeros) to work well with this combo |
| 19:35.13 | khem | so far gstreamer-omx is helpting with omx path |
| 19:35.41 | khem | eventually when we have v4l2 for rpi then it would be great we can hopefully drop omx completely |
| 19:36.08 | khem | I want to merge userland-nogl and userland recipes into 1 as well |
| 19:36.21 | JaMa | eventually yes, but fkms doesn't seem to be ready for prime time and vc4-kms-v3d isn't meant to play nice together with userland for multimedia |
| 19:36.26 | khem | and operate based on vc4graphics DISTRO_FEATURE |
| 19:36.57 | khem | fkms is a stepping stone |
| 19:38.20 | JaMa | https://github.com/Comcast/rdk-on-raspberrypi says to BBMASK whole recipes-qt, is there something public which already shows how you're using Qt in RDK with rpi? |
| 19:38.46 | JaMa | I've seen that qtbase bbappend in meta-raspberrypi, just wondering about the other bits |
| 19:39.09 | *** join/#oe dqx_ (~dqx@unaffiliated/dqx) |
| 19:41.56 | *** join/#oe dqx_ (~dqx@unaffiliated/dqx) |
| 19:43.42 | khem | JaMa: yes, that is best version |
| 19:43.47 | khem | we dont use qt |
| 19:44.17 | khem | but wayland+westros+spark+wpe |
| 19:44.28 | khem | spark is another native rendering engine |
| 19:48.58 | *** join/#oe tprrt (~tprrt@ram31-1-82-234-79-177.fbx.proxad.net) |
| 20:22.31 | *** join/#oe Jybz (~jibz@ip-37-201-6-197.hsi13.unitymediagroup.de) |
| 20:50.48 | *** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa) |
| 21:10.37 | *** join/#oe Bunio_FH (~bunio@clj-165.netdrive.pl) |
| 21:20.16 | *** join/#oe ao2 (~ao2@87.19.23.4) |
| 21:46.52 | *** join/#oe mattsm (~mattsm@76.205.175.243) |
| 22:39.01 | *** join/#oe Jybz (~jibz@2a02:8071:9289:5900:4a51:b7ff:fe84:99e6) |
| 22:52.39 | *** join/#oe tprrt (~tprrt@ram31-1-82-234-79-177.fbx.proxad.net) |
| 23:27.52 | *** join/#oe maelcum (~horst@200116b84287170075cacd155ace7641.dip.versatel-1u1.de) |
| 23:28.00 | *** join/#oe dqx (~dqx@unaffiliated/dqx) |