| calebtheythem[m] | ajr: and UART diagram- https://wiki.postmarketos.org/wiki/Serial_debugging:Cable_schematics#Motorola_Photon_Q_.28asanti_.2F_xt897.29 | 02:58 |
|---|---|---|
| dsc_ | would be nice of maemo by default would pick qt5 as the installation of choice, i.e this does not work: | 08:54 |
| dsc_ | s/of/if/ | 08:54 |
| dsc_ | # qmake | 08:55 |
| dsc_ | qmake: could not find a Qt installation of '' | 08:55 |
| dsc_ | while this works: | 08:55 |
| dsc_ | # QT_SELECT=5 qmake -v | 08:55 |
| dsc_ | QMake version 3.1 | 08:55 |
| dsc_ | without env. variable, it will check these locations for a config file: $USER/.config/qtchooser/, /etc/xdg/qtchooser/, /usr/share/qtchooser/, /usr/lib/x86_64-linux-gnu/qtchooser/, /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/ | 08:56 |
| dsc_ | none of these places exist | 08:56 |
| dsc_ | perhaps the package `qtchooser` should be responsible for providing that config file so that you can use `qmake` (and friends) without manually specifying the presence of a Qt installation | 09:00 |
| dsc_ | during compilation I want to use the binary `qmlcachegen` (via CMake's `qtquick_compiler_add_resources()`) and that binary like `qmake` also relies on either the env. variable being present or the config file to point to a Qt installation (CMake is appearantly not smart enough to call this process with the required Qt5 installation that was discovered from an earlier `find_package(Qt5 ...)`) | 09:08 |
| * dsc_ cries in CMake | 09:09 | |
| dsc_ | ehhh.. /usr/lib/x86_64-linux-gnu/qt5/qt.conf does exist | 09:19 |
| dsc_ | and /usr/share/qtchooser/qt5-x86_64-linux-gnu.conf also exists | 09:21 |
| dsc_ | but yeah would be nice of `qmake` and `qmlcachegen` would work without manually having to specify the Qt version to use | 09:23 |
| Wizzup | hmm | 09:57 |
| Wizzup | dsc_: didn't even realise it still supported qt4 btw | 10:06 |
| dsc_ | Wizzup: Yeah I noticed that hehe | 10:06 |
| lel | sanderfoobar opened a pull request: https://github.com/maemo-leste/conversations/pull/6 (precompile QML) | 10:22 |
| Wizzup | dsc_: btw i think you can depend on a package that makes qt5 the default | 12:16 |
| Wizzup | dsc_: qt5-default | 12:27 |
| Wizzup | dsc_: maybe just add that to build-depends | 12:27 |
| dsc_ | Wizzup: ahhh | 12:41 |
| dsc_ | there we go | 12:41 |
| lel | sanderfoobar synchronize a pull request: https://github.com/maemo-leste/conversations/pull/6 (precompile QML) | 12:46 |
| lel | sanderfoobar synchronize a pull request: https://github.com/maemo-leste/conversations/pull/6 (precompile QML) | 12:47 |
| lel | sanderfoobar closed a pull request: https://github.com/maemo-leste/conversations/pull/6 (precompile QML) | 12:48 |
| lel | sanderfoobar closed an issue: https://github.com/maemo-leste/conversations/issues/5 (Precompile QML) | 12:48 |
| uvos | dsc_: neat, how mutch dose that help startup times? | 13:11 |
| uvos | maybe dont pr on packages you own yourself and use branches instead gets pretty spammy otherwise. | 13:11 |
| uvos | or maybe parazyd can add a exception to lel | 13:11 |
| Wizzup | I don't think it's super spammy atm | 13:12 |
| Wizzup | calebtheythem[m]: btw I might have missed something but I didn't see any 'ajr' | 13:13 |
| dsc_ | uvos: not sure tbh but it skips runtime QML compilation, surely it will help a bit | 13:17 |
| dsc_ | ill just push to master </yolo> | 13:22 |
| Wizzup | I think the PRs are nice, also for the news posts | 13:22 |
| uvos | Im fine with it, if Wizzup wants them. but please, not too manny. | 13:23 |
| dsc_ | would be nice if lel used NOTICE instead of PRIVMSG | 13:23 |
| Wizzup | I probably spam 50x more every day than the PRs ;P | 13:23 |
| bencoh | yeah, /notice would be better | 13:35 |
| bencoh | (although I know some (misconfigured?) clients show notices as highlights, which is worse for their users) | 13:35 |
| lel | Dastan-glitch opened a pull request: https://github.com/maemo-leste/liblocation/pull/1 (More readable code + factors) | 14:23 |
| mighty17[m] | <mighty17[m]> "Is the twl6030/6032 gpadc..." <- bump anyone knows? | 17:23 |
| uvos | mighty17[m]: did you grep in kernel for a user? | 17:28 |
| mighty17[m] | uvos: for a user? | 17:29 |
| uvos | a user of the dts bindings | 17:29 |
| mighty17[m] | https://github.com/torvalds/linux/blob/master/drivers/iio/adc/twl6030-gpadc.c#L852 | 17:29 |
| uvos | right and greping for the compatibile dosent get you some other board that uses this pmic feature to use as an example? | 17:30 |
| uvos | or am i missunderstanding what you need | 17:31 |
| mighty17[m] | uvos: nope | 17:32 |
| uvos | hmm | 17:32 |
| mighty17[m] | only twl6030.dtsi (which ofc has it) | 17:32 |
| uvos | i dont understand what the problem is then | 17:33 |
| uvos | whats wrong with the node in twl6030 | 17:33 |
| mighty17[m] | https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/ste-ux500-samsung-janice.dts#L292-L298 i need to so smth like here | 17:35 |
| uvos | mighty17[m]: the mainline driver dosent support conversion of some adc channel to a current via giveing it a shunt value | 17:38 |
| uvos | to my knowlage this kind of calculation is frowned upon in upstream iio drivers | 17:39 |
| uvos | (but this "rule" is often violated) | 17:39 |
| mighty17[m] | but well i do need to get my light+proximity sensor working :( | 17:39 |
| uvos | you need to add this feature to the driver (looks very easy at glance) | 17:39 |
| uvos | or do the conversion in userspace | 17:39 |
| mighty17[m] | https://github.com/torvalds/linux/commit/754718a5b43c851546c3bb70e8d41bf81cb42b30 like here? | 17:40 |
| uvos | mighty17[m]: so wait | 17:40 |
| uvos | you have a light sensor | 17:40 |
| uvos | thats just a photodiode? | 17:40 |
| uvos | and the adc reads it? | 17:40 |
| uvos | in this case | 17:40 |
| uvos | you need to write a new iio driver | 17:40 |
| uvos | that uses the adc in kernel | 17:40 |
| uvos | to provide the lux value | 17:41 |
| mighty17[m] | i have https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/iio/light/sharp,gp2ap002.yaml#L20 | 17:41 |
| MartijnBraam[m] | can maemo leste run on armel? | 17:41 |
| mighty17[m] | uvos: so i need to make a new driver for the gpadc, why for the iio? | 17:42 |
| MartijnBraam[m] | specifically ARMv6 softfloat | 17:42 |
| uvos | MartijnBraam[m]: no | 17:42 |
| uvos | MartijnBraam[m]: you could build it yourself ofc | 17:42 |
| MartijnBraam[m] | rip | 17:42 |
| MartijnBraam[m] | well ofcourse, no softfloat device has maemo support so would require some porting | 17:42 |
| uvos | we only build amd64, arm64 and armhf | 17:43 |
| * MartijnBraam[m] uploaded an image: (1076KiB) < https://libera.ems.host/_matrix/media/r0/download/brixit.nl/oOxbsuxLatJcfiiDcgDojRFF/PXL_20211207_162735988%20(1).jpg > | 17:43 | |
| uvos | t-mobile g1 | 17:43 |
| uvos | uff :P | 17:43 |
| uvos | 192mb ram no? | 17:43 |
| MartijnBraam[m] | something like that yes | 17:45 |
| MartijnBraam[m] | pretty nice keyboard | 17:45 |
| uvos | uh | 17:45 |
| uvos | i hated it | 17:45 |
| uvos | but ok | 17:45 |
| uvos | mighty17[m]: you dont have to write a new driver | 17:45 |
| uvos | im still not sure what the problem is | 17:45 |
| MartijnBraam[m] | I've used way worse keyboards, it's not as good as the n900 one | 17:45 |
| uvos | looks like gp2ap002a00f outputs a voltage | 17:45 |
| mighty17[m] | uvos: even i dont know, the driver outputs nothing, but hwtest says its broken | 17:46 |
| uvos | and you sould be able to specify the adc channel no problem | 17:46 |
| uvos | im not sure why they want to mesure the current of some shunt in the linked dts | 17:46 |
| uvos | but then again idk how your hw works | 17:46 |
| uvos | but this seams wrong | 17:46 |
| mighty17[m] | uvos: well only 2 devices use that gp2ap002a00f and both do it like that | 17:47 |
| mighty17[m] | https://github.com/torvalds/linux/commit/7c558af511d01ef0ab0fe1692517f80d27e17cc3 | 17:47 |
| uvos | ah ok dts is wrong and that sensor outputs a current | 17:47 |
| uvos | *dts documentation | 17:48 |
| mighty17[m] | ow :o | 17:49 |
| uvos | mighty17[m]: but then you just need https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml | 17:50 |
| uvos | no? | 17:50 |
| uvos | its a driver that takes a iio voltage adc channel | 17:50 |
| uvos | and converts it to current | 17:50 |
| uvos | and you get a current adc channel | 17:50 |
| uvos | that you can give the driver | 17:51 |
| mighty17[m] | thats what i did | 17:51 |
| mighty17[m] | but it doesnt want to work | 17:51 |
| uvos | right ok | 17:52 |
| uvos | im up to speed then :P | 17:52 |
| mighty17[m] | https://paste.debian.net/1222454/ | 17:52 |
| mighty17[m] | :D | 17:52 |
| uvos | so what dosent work exactly | 17:54 |
| uvos | dose just haveing the current-sense-shunt wihtout the als chip | 17:54 |
| uvos | give you an iio device? | 17:54 |
| uvos | also do you get the adc channel that you expect | 17:56 |
| uvos | as an iio device | 17:56 |
| mighty17[m] | wait wait wait | 17:57 |
| mighty17[m] | uvos: that should be in /dev/iio? | 17:57 |
| uvos | mighty17[m]: yeah sure the adc device shoule be created at /sys/bus/iio/devices | 17:59 |
| uvos | you should have at least in_voltage*_raw for eatch channel | 18:00 |
| mighty17[m] | `in_current0_raw in_current0_scale name of_node power subsystem uevent` | 18:00 |
| mighty17[m] | it is in `/sys/devices/platform/current-sense-shunt/iio:device3` | 18:00 |
| uvos | mighty17[m]: so the current shut works fine | 18:00 |
| uvos | so everything up to this point is fine | 18:00 |
| uvos | i suspect | 18:00 |
| uvos | (check if the number change when you change the light) | 18:00 |
| uvos | (dont forget the enable pin of the als if any) | 18:01 |
| mighty17[m] | i dunno what app to use | 18:01 |
| uvos | cat | 18:01 |
| uvos | you can just cat in_current0_raw | 18:01 |
| mighty17[m] | uvos: done, the int pin | 18:01 |
| uvos | so with the enable pin pulled high/low (whatever is active) dose cat in_current0_raw work fine? | 18:02 |
| uvos | and reflect the light? | 18:02 |
| mighty17[m] | uvos: i get no output with `cat in_current0_raw` | 18:02 |
| mighty17[m] | `cat: read error: Operation timed out` | 18:03 |
| uvos | ok so move up a device | 18:03 |
| uvos | dose the same error occure if you read in_voltage14_raw on the adc? | 18:03 |
| mighty17[m] | uvos: yes | 18:05 |
| uvos | only for this channel? | 18:05 |
| uvos | or all channels? | 18:05 |
| mighty17[m] | uvos: `in_temp1_raw in_voltage10_input in_voltage2_input in_voltage6_input in_voltage9_input power | 18:06 |
| mighty17[m] | in_temp4_raw in_voltage11_raw in_voltage3_input in_voltage7_input name subsystem | 18:06 |
| mighty17[m] | in_voltage0_input in_voltage14_input in_voltage5_input in_voltage8_input of_node uevent` | 18:06 |
| mighty17[m] | 14_raw doesnt exist? | 18:06 |
| mighty17[m] | uvos: and yes `in_temp1_raw` also times out | 18:07 |
| uvos | ok so your adc dosent work at all | 18:08 |
| uvos | maybe the conversion intterupt line is wrong | 18:08 |
| uvos | conversion finished that is | 18:08 |
| uvos | also you have a slightly different pmic no? | 18:08 |
| uvos | maybe some registers are different | 18:08 |
| uvos | check differences in datasheet if you have it | 18:09 |
| mighty17[m] | uvos: twl6030-gpadc driver doesnt complain in dmesg tho :( | 18:10 |
| uvos | it would not if the intterupt is wrong | 18:10 |
| mighty17[m] | uvos: yeah but it is supported by twl6030-gpadc https://github.com/torvalds/linux/blob/master/drivers/iio/adc/twl6030-gpadc.c#L858 | 18:10 |
| mighty17[m] | :o but interrupt is correct afaik | 18:11 |
| mighty17[m] | wait u mean the gpadc also needs an interrupt? i only have the ALS_INT | 18:11 |
| uvos | mighty17[m]: sure https://github.com/torvalds/linux/blob/cd8c917a56f20f48748dd43d9ae3caff51d5b987/drivers/iio/adc/twl6030-gpadc.c#L911 | 18:13 |
| uvos | it has a conversion finished irq | 18:13 |
| uvos | clearly its not fireing | 18:13 |
| uvos | so you have to figure out why | 18:13 |
| mighty17[m] | <mighty17[m]> "https://paste.debian.net/1222454..." <- this is correct right? | 18:15 |
| mighty17[m] | does no device use twl6030 gpadc? damn | 18:31 |
| mighty17[m] | ok definitely something wrong in enabling twl6032-gpadc, how do i debug it? am i missing some reg for it? | 18:59 |
| devrtz[m] | Hey there, just wanted to let you know that there is now a CfP for the FOSS on mobile devroom @FOSDEM: https://fosdem.org/2022/schedule/track/foss_on_mobile_devices/ | 19:02 |
| uvos | great | 20:20 |
| Wizzup | MartijnBraam[m]: we had armel builds before | 20:35 |
| Wizzup | MartijnBraam[m]: it wouldn't be too hard to add again I suppose | 20:35 |
| Wizzup | I mean, it would be quite some work, but not hard work | 20:36 |
| Wizzup | the photon q slides differently than the d4 | 20:47 |
| Wizzup | it feels more like the n900 | 20:47 |
| uvos | yeah | 20:48 |
| uvos | also the display is miles better | 20:48 |
| uvos | (when it dosent break that is) | 20:48 |
| MartijnBraam[m] | the photon q looks so nice, so unavailable though | 20:49 |
| Wizzup | also 20 xt610 arrived | 20:51 |
| * Wizzup puts them away for later | 20:51 | |
| Wizzup | ... in like a year | 20:51 |
| MartijnBraam[m] | droid pro | 20:51 |
| MartijnBraam[m] | what's that | 20:51 |
| MartijnBraam[m] | oh with the blackberry style keyboard | 20:51 |
| MartijnBraam[m] | POWERVR | 20:51 |
| uvos | droid 1 in a blackbarry formfactor | 20:51 |
| Wizzup | yeah | 20:52 |
| uvos | droid 1 is like n900 essantaly a omap3 referance implementation | 20:52 |
| uvos | so they are are exteamly samey | 20:52 |
| Wizzup | mhm | 21:09 |
| Wizzup | they're light | 21:09 |
| Wizzup | (without battery) | 21:09 |
| calebtheythem[m] | all this photon Q talk oo | 22:10 |
| bencoh | photon q features a snapdragon though ... | 23:26 |
| Wizzup | yeah | 23:26 |
| bencoh | with a modem-in-soc design, iirc | 23:27 |
| Wizzup | mhm | 23:47 |
| Wizzup | but it slides nice :) | 23:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!