00:07
ruleh has quit [Ping timeout: 256 seconds]
00:20
elastic_dog has quit [Ping timeout: 265 seconds]
00:25
elastic_dog has joined #maemo-leste
00:34
uvos has quit [Ping timeout: 265 seconds]
01:20
eniac_petrov has quit [Ping timeout: 252 seconds]
01:35
Pali has quit [Ping timeout: 265 seconds]
03:00
xmn has joined #maemo-leste
03:16
cockroach has quit [Quit: leaving]
04:46
ikmaak has quit [Ping timeout: 252 seconds]
04:47
ikmaak has joined #maemo-leste
05:05
xmn has quit [Ping timeout: 265 seconds]
05:32
joerg has quit [Ping timeout: 252 seconds]
05:33
joerg has joined #maemo-leste
06:00
mardy has joined #maemo-leste
06:28
eniac_petrov has joined #maemo-leste
06:40
eniac_petrov has quit [Ping timeout: 252 seconds]
07:31
avoidr has quit [Ping timeout: 252 seconds]
07:34
avoidr has joined #maemo-leste
07:54
<
dsc_ >
would be nice of maemo by default would pick qt5 as the installation of choice, i.e this does not work:
07:55
<
dsc_ >
qmake: could not find a Qt installation of ''
07:55
<
dsc_ >
while this works:
07:55
<
dsc_ >
# QT_SELECT=5 qmake -v
07:55
<
dsc_ >
QMake version 3.1
07:56
<
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/
07:56
<
dsc_ >
none of these places exist
08:00
<
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
08:08
<
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 ...)`)
08:09
* dsc_
cries in CMake
08:19
<
dsc_ >
ehhh.. /usr/lib/x86_64-linux-gnu/qt5/qt.conf does exist
08:21
<
dsc_ >
and /usr/share/qtchooser/qt5-x86_64-linux-gnu.conf also exists
08:23
<
dsc_ >
but yeah would be nice of `qmake` and `qmlcachegen` would work without manually having to specify the Qt version to use
08:58
eniac_petrov has joined #maemo-leste
09:06
<
Wizzup >
dsc_: didn't even realise it still supported qt4 btw
09:06
<
dsc_ >
Wizzup: Yeah I noticed that hehe
09:30
uvos has joined #maemo-leste
09:48
Pali has joined #maemo-leste
10:40
ruleh has joined #maemo-leste
11:16
<
Wizzup >
dsc_: btw i think you can depend on a package that makes qt5 the default
11:21
elastic_dog has quit [Ping timeout: 240 seconds]
11:26
elastic_dog has joined #maemo-leste
11:27
<
Wizzup >
dsc_: qt5-default
11:27
<
Wizzup >
dsc_: maybe just add that to build-depends
11:41
<
dsc_ >
Wizzup: ahhh
12:02
ruleh has quit [Quit: Client closed]
12:11
<
uvos >
dsc_: neat, how mutch dose that help startup times?
12:11
<
uvos >
maybe dont pr on packages you own yourself and use branches instead gets pretty spammy otherwise.
12:11
<
uvos >
or maybe parazyd can add a exception to lel
12:12
<
Wizzup >
I don't think it's super spammy atm
12:13
<
Wizzup >
calebtheythem[m]: btw I might have missed something but I didn't see any 'ajr'
12:17
<
dsc_ >
uvos: not sure tbh but it skips runtime QML compilation, surely it will help a bit
12:22
<
dsc_ >
ill just push to master </yolo>
12:22
<
Wizzup >
I think the PRs are nice, also for the news posts
12:23
<
uvos >
Im fine with it, if Wizzup wants them. but please, not too manny.
12:23
<
dsc_ >
would be nice if lel used NOTICE instead of PRIVMSG
12:23
<
Wizzup >
I probably spam 50x more every day than the PRs ;P
12:35
<
bencoh >
yeah, /notice would be better
12:35
<
bencoh >
(although I know some (misconfigured?) clients show notices as highlights, which is worse for their users)
13:17
_inky has quit [Ping timeout: 265 seconds]
13:20
inky has quit [Ping timeout: 265 seconds]
13:24
inky has joined #maemo-leste
13:28
cockroach has joined #maemo-leste
13:34
_inky has joined #maemo-leste
13:36
mepy has joined #maemo-leste
13:51
pere has quit [Ping timeout: 265 seconds]
13:52
_inky has quit [Ping timeout: 265 seconds]
13:54
_inky has joined #maemo-leste
14:44
alex1216 has joined #maemo-leste
14:45
alex1216 is now known as alex352b
14:46
alex352b is now known as alex1216
15:09
pere has joined #maemo-leste
15:39
_inky has quit [Read error: Connection reset by peer]
15:39
inky has quit [Read error: Connection reset by peer]
15:40
inky has joined #maemo-leste
15:53
alex1216 has quit [Quit: Leaving office, laptop will be in standby anyway.]
15:59
_inky has joined #maemo-leste
16:23
<
mighty17[m] >
<mighty17[m]> "Is the twl6030/6032 gpadc..." <- bump anyone knows?
16:28
<
uvos >
mighty17[m]: did you grep in kernel for a user?
16:29
<
mighty17[m] >
uvos: for a user?
16:29
<
uvos >
a user of the dts bindings
16:30
<
uvos >
right and greping for the compatibile dosent get you some other board that uses this pmic feature to use as an example?
16:31
<
uvos >
or am i missunderstanding what you need
16:32
<
mighty17[m] >
uvos: nope
16:32
<
mighty17[m] >
only twl6030.dtsi (which ofc has it)
16:33
<
uvos >
i dont understand what the problem is then
16:33
<
uvos >
whats wrong with the node in twl6030
16:38
<
uvos >
mighty17[m]: the mainline driver dosent support conversion of some adc channel to a current via giveing it a shunt value
16:39
<
uvos >
to my knowlage this kind of calculation is frowned upon in upstream iio drivers
16:39
<
uvos >
(but this "rule" is often violated)
16:39
<
mighty17[m] >
but well i do need to get my light+proximity sensor working :(
16:39
<
uvos >
you need to add this feature to the driver (looks very easy at glance)
16:39
<
uvos >
or do the conversion in userspace
16:40
<
uvos >
mighty17[m]: so wait
16:40
<
uvos >
you have a light sensor
16:40
<
uvos >
thats just a photodiode?
16:40
<
uvos >
and the adc reads it?
16:40
<
uvos >
in this case
16:40
<
uvos >
you need to write a new iio driver
16:40
<
uvos >
that uses the adc in kernel
16:41
<
uvos >
to provide the lux value
16:41
<
MartijnBraam[m] >
can maemo leste run on armel?
16:42
<
mighty17[m] >
uvos: so i need to make a new driver for the gpadc, why for the iio?
16:42
<
MartijnBraam[m] >
specifically ARMv6 softfloat
16:42
<
uvos >
MartijnBraam[m]: no
16:42
<
uvos >
MartijnBraam[m]: you could build it yourself ofc
16:42
<
MartijnBraam[m] >
rip
16:42
<
MartijnBraam[m] >
well ofcourse, no softfloat device has maemo support so would require some porting
16:43
<
uvos >
we only build amd64, arm64 and armhf
16:43
<
uvos >
192mb ram no?
16:45
<
MartijnBraam[m] >
something like that yes
16:45
<
MartijnBraam[m] >
pretty nice keyboard
16:45
<
uvos >
mighty17[m]: you dont have to write a new driver
16:45
<
uvos >
im still not sure what the problem is
16:45
<
MartijnBraam[m] >
I've used way worse keyboards, it's not as good as the n900 one
16:45
<
uvos >
looks like gp2ap002a00f outputs a voltage
16:46
<
mighty17[m] >
uvos: even i dont know, the driver outputs nothing, but hwtest says its broken
16:46
<
uvos >
and you sould be able to specify the adc channel no problem
16:46
<
uvos >
im not sure why they want to mesure the current of some shunt in the linked dts
16:46
<
uvos >
but then again idk how your hw works
16:46
<
uvos >
but this seams wrong
16:47
<
mighty17[m] >
uvos: well only 2 devices use that gp2ap002a00f and both do it like that
16:47
<
uvos >
ah ok dts is wrong and that sensor outputs a current
16:48
<
uvos >
*dts documentation
16:49
<
mighty17[m] >
ow :o
16:50
<
uvos >
its a driver that takes a iio voltage adc channel
16:50
<
uvos >
and converts it to current
16:50
<
uvos >
and you get a current adc channel
16:51
<
uvos >
that you can give the driver
16:51
<
mighty17[m] >
thats what i did
16:51
<
mighty17[m] >
but it doesnt want to work
16:52
<
uvos >
im up to speed then :P
16:54
<
uvos >
so what dosent work exactly
16:54
<
uvos >
dose just haveing the current-sense-shunt wihtout the als chip
16:54
<
uvos >
give you an iio device?
16:56
<
uvos >
also do you get the adc channel that you expect
16:56
<
uvos >
as an iio device
16:57
<
mighty17[m] >
wait wait wait
16:57
<
mighty17[m] >
uvos: that should be in /dev/iio?
16:59
<
uvos >
mighty17[m]: yeah sure the adc device shoule be created at /sys/bus/iio/devices
17:00
<
uvos >
you should have at least in_voltage*_raw for eatch channel
17:00
<
mighty17[m] >
`in_current0_raw in_current0_scale name of_node power subsystem uevent`
17:00
<
mighty17[m] >
it is in `/sys/devices/platform/current-sense-shunt/iio:device3`
17:00
<
uvos >
mighty17[m]: so the current shut works fine
17:00
<
uvos >
so everything up to this point is fine
17:00
<
uvos >
(check if the number change when you change the light)
17:01
<
uvos >
(dont forget the enable pin of the als if any)
17:01
<
mighty17[m] >
i dunno what app to use
17:01
<
uvos >
you can just cat in_current0_raw
17:01
<
mighty17[m] >
uvos: done, the int pin
17:02
<
uvos >
so with the enable pin pulled high/low (whatever is active) dose cat in_current0_raw work fine?
17:02
<
uvos >
and reflect the light?
17:02
<
mighty17[m] >
uvos: i get no output with `cat in_current0_raw`
17:03
<
mighty17[m] >
`cat: read error: Operation timed out`
17:03
<
uvos >
ok so move up a device
17:03
<
uvos >
dose the same error occure if you read in_voltage14_raw on the adc?
17:04
eniac_petrov has quit [Ping timeout: 268 seconds]
17:05
<
mighty17[m] >
uvos: yes
17:05
<
uvos >
only for this channel?
17:05
<
uvos >
or all channels?
17:06
<
mighty17[m] >
uvos: `in_temp1_raw in_voltage10_input in_voltage2_input in_voltage6_input in_voltage9_input power
17:06
<
mighty17[m] >
in_temp4_raw in_voltage11_raw in_voltage3_input in_voltage7_input name subsystem
17:06
<
mighty17[m] >
in_voltage0_input in_voltage14_input in_voltage5_input in_voltage8_input of_node uevent`
17:06
<
mighty17[m] >
14_raw doesnt exist?
17:07
<
mighty17[m] >
uvos: and yes `in_temp1_raw` also times out
17:08
<
uvos >
ok so your adc dosent work at all
17:08
<
uvos >
maybe the conversion intterupt line is wrong
17:08
<
uvos >
conversion finished that is
17:08
<
uvos >
also you have a slightly different pmic no?
17:08
<
uvos >
maybe some registers are different
17:09
<
uvos >
check differences in datasheet if you have it
17:10
<
mighty17[m] >
uvos: twl6030-gpadc driver doesnt complain in dmesg tho :(
17:10
<
uvos >
it would not if the intterupt is wrong
17:11
<
mighty17[m] >
:o but interrupt is correct afaik
17:11
<
mighty17[m] >
wait u mean the gpadc also needs an interrupt? i only have the ALS_INT
17:13
<
uvos >
it has a conversion finished irq
17:13
<
uvos >
clearly its not fireing
17:13
<
uvos >
so you have to figure out why
17:31
<
mighty17[m] >
does no device use twl6030 gpadc? damn
17:48
Blikje has quit [Remote host closed the connection]
17:59
<
mighty17[m] >
ok definitely something wrong in enabling twl6032-gpadc, how do i debug it? am i missing some reg for it?
18:10
joerg has quit [Read error: Connection reset by peer]
18:15
joerg has joined #maemo-leste
18:18
Blikje_ has joined #maemo-leste
18:30
Blikje_ is now known as Blikje
19:35
<
Wizzup >
MartijnBraam[m]: we had armel builds before
19:35
<
Wizzup >
MartijnBraam[m]: it wouldn't be too hard to add again I suppose
19:36
<
Wizzup >
I mean, it would be quite some work, but not hard work
19:47
<
Wizzup >
the photon q slides differently than the d4
19:47
<
Wizzup >
it feels more like the n900
19:48
<
uvos >
also the display is miles better
19:48
<
uvos >
(when it dosent break that is)
19:49
<
MartijnBraam[m] >
the photon q looks so nice, so unavailable though
19:51
<
Wizzup >
also 20 xt610 arrived
19:51
* Wizzup
puts them away for later
19:51
<
Wizzup >
... in like a year
19:51
<
MartijnBraam[m] >
droid pro
19:51
<
MartijnBraam[m] >
what's that
19:51
<
MartijnBraam[m] >
oh with the blackberry style keyboard
19:51
<
MartijnBraam[m] >
POWERVR
19:51
<
uvos >
droid 1 in a blackbarry formfactor
19:52
<
uvos >
droid 1 is like n900 essantaly a omap3 referance implementation
19:52
<
uvos >
so they are are exteamly samey
20:09
<
Wizzup >
they're light
20:09
<
Wizzup >
(without battery)
20:16
alex1216 has joined #maemo-leste
21:01
alex1216 has quit [Quit: WeeChat 2.3]
21:10
<
calebtheythem[m] >
all this photon Q talk oo
22:15
mardy has quit [Quit: WeeChat 2.8]
22:26
<
bencoh >
photon q features a snapdragon though ...
22:27
<
bencoh >
with a modem-in-soc design, iirc
22:47
<
Wizzup >
but it slides nice :)
22:50
xmn has joined #maemo-leste
22:59
TonyStone has quit [Remote host closed the connection]
23:04
TonyStone has joined #maemo-leste