<duuude>
leste also reconnects to wifi on its own, whereas I had disconnected it
duuude has quit [Read error: Connection reset by peer]
duuude has joined #maemo-leste
nela has joined #maemo-leste
xmn has quit [Read error: Connection reset by peer]
diejuse has quit [Quit: Client closed]
xmn has joined #maemo-leste
duuude has quit [Ping timeout: 260 seconds]
xmn has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
<tmlind>
freemangordon: hmm yeah the wakeirq should be for each port
<tmlind>
anyways it should be one of the pins from padconftodts | grep usbb1_ulpitll | grep -v gpio_
<tmlind>
i think one of the pins should be enough..
<tmlind>
freemangordon: maybe omap-usb-host.c should have an instance per port, the ti-sysc might be enough for a generic parent driver
<tmlind>
freemangordon: so for example dts wakeirq for pad 0x4a1000d0 usbb1_ulpitll_dat3.usbb1_mm_rxrcv is at <&omap4_pmx_core 0x90>, where 0x90 is 0xd0 - 0x40 padconf start offset
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
<freemangordon>
tmlind: ok, but I don;t understand why it does not wokr now, given that USB supports remote wake-up by design
<freemangordon>
and OHCI in dts is set as remote-wakeup-connected;
<freemangordon>
so, my understanding is that modem is connected to ohci using 4 pin configuration
<freemangordon>
from the TRM:
<freemangordon>
The FSUSB host controller interface asserts wakeup from suspend when the wake-up conditions occur (such as remote signaling on port, device connect/disconnect) and the FSUSB host controller is in idle mode.
duuude has quit [Read error: Connection reset by peer]
<freemangordon>
tmlind: I think the requirements in 23.13.4.2.2 IDLE Protocol are not fulfilled, I am not able to find who sets HCOCPSYS IDLE_MODE bits
<freemangordon>
and there are no ti,sysc entries in DTS for the ports, if that's even possibel
mdz has quit [Ping timeout: 256 seconds]
mdz has joined #maemo-leste
arno11 has joined #maemo-leste
mdz has quit [Ping timeout: 272 seconds]
<arno11>
duuude: you should check your settings in Internet connections: 'connect automatically' and 'Search interval'
<arno11>
and for the battery, no worries, just a bug in the applet. charging is ok
arno11 has left #maemo-leste [#maemo-leste]
pere_ has quit [Ping timeout: 255 seconds]
duuude has joined #maemo-leste
Juest has quit [Ping timeout: 268 seconds]
ceene has quit [Ping timeout: 256 seconds]
Juest has joined #maemo-leste
duuude has quit [Ping timeout: 255 seconds]
diejuse has joined #maemo-leste
diejuse has quit [Ping timeout: 250 seconds]
duuude has joined #maemo-leste
ceene has joined #maemo-leste
<freemangordon>
tmlind: wait, I thing we're approaching that wrong
<freemangordon>
*thin
<freemangordon>
think
<freemangordon>
it is the modem itself that needs autosuspend disabled
<freemangordon>
not ohci or whatever
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #maemo-leste
Langoor has quit [Ping timeout: 260 seconds]
xmn has joined #maemo-leste
pere_ has joined #maemo-leste
diejuse has joined #maemo-leste
Langoor has joined #maemo-leste
mdz has joined #maemo-leste
ungeskriptet6 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 260 seconds]
ungeskriptet6 is now known as ungeskriptet
moparisthebest has quit [Ping timeout: 260 seconds]
diejuse has quit [Ping timeout: 250 seconds]
ceene has quit [Ping timeout: 268 seconds]
pere_ has quit [Ping timeout: 264 seconds]
k1r1t0 has quit [Quit: Lost terminal]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #maemo-leste
diejuse has joined #maemo-leste
<diejuse>
I'm testing a KDE application, the Kate text editor specifically. In kde applications some submenus are displayed and seen correctly and others are not. That doesn't happen if I open the same application in another environment other than Maemo Leste. Any solution?
<gnarface>
sounds like a graphics driver issue
<gnarface>
i don't really know though, stick around someone might
<gnarface>
make sure to mention your phone model
<gnarface>
(it's probably specific to that one phone)
<diejuse>
it is not a phone model problem, for sure
<diejuse>
you can try it installing kate, for example
<gnarface>
you're seeing it on other phone models too?
<gnarface>
my theory was that it's specific to the graphics driver on your particular phone, not the phone hardware itself, but i don't actually know, it was just a guess
<diejuse>
Yeah. Furthermore, if I open the same application on another desktop other than Hildon, there is no such problem.
<diejuse>
Also, the submenus open correctly in Maemo if I open the app with Xephyr.
<gnarface>
hmm, strange
<gnarface>
maybe it's a problem with the xorg build
<gnarface>
it's using xorg, not wayland, right?
<diejuse>
To identify the issue, it's best for you to test it yourself to see if you encounter the same problem on your native Maemo. I'm confident that you will experience the same issue, and it's independent of the phone model.
<Wizzup>
it might make sense to specify exactly what the problem is that you are seeing
<freemangordon>
I don;t think we support sub-menus
<diejuse>
I open 'kate' -> I click on 'tools' (for example) in the menu -> it expands correctly -> I click on another submenu within 'tools' -> nothing is displayed.
<diejuse>
But if I open 'kate' within Xephyr or in another desktop environment that is not Hildon, everything works fine
<Wizzup>
yes, submenus are not supported
<Wizzup>
I think diejuse is saying 'works fine' means it's the regular qt menu render
<Wizzup>
not that maemo does submenus
<diejuse>
Oh, I didn't know it didn't support "submenus". Do you not use applications that use submenus on your phones with Maemo (Nokia N900, Droid4)?
<freemangordon>
native applications have different UI than desktop ones
<diejuse>
I understand. But I imagine that you will use other applications that are not native. It's annoying not being able to access the submenus.
<diejuse>
The workaround I have found is to open them through Xephyr.
<diejuse>
Sorry if my English is not understood many times.
<Wizzup>
you can disable the qt platform plugin in the env var and it will work like desktop
<diejuse>
QT_QPA_PLATFORM= ?
<freemangordon>
QT_QPA_PLATFORM=xcb
<freemangordon>
Wizzup: right?
<gnarface>
diejuse: sorry, i didn't realize any of this
duuude has quit [Ping timeout: 255 seconds]
<diejuse>
With QT_QPA_PLATFORM=xcb the submenus are still not shown.
<freemangordon>
try windows or some other
<diejuse>
Ok, I'll try combinations.
<Wizzup>
you can just unset it, but you also need to stop the theme
<Wizzup>
stop as in, also remove it form env
duuude has joined #maemo-leste
<diejuse>
I think doing what you say still doesn't work. Try it if you have time.
<Wizzup>
$ env|grep QT
<Wizzup>
QT_STYLE_OVERRIDE=maemo5
<Wizzup>
QT_QPA_PLATFORM=maemo
<Wizzup>
unset QT_STYLE_OVERRIDE
<Wizzup>
unset QT_QPA_PLATFORM
<Wizzup>
run your program
<diejuse>
Yes, I had already done it and I just did it again. Kate's submenus are still not showing
<gnarface>
would these variables not need to be set in the environment before the window server starts?
<sicelo>
duuude: arno11: would you like to test a patch for the 'charging-when-full' problem? https://paste.debian.net/1308252/ ... let me know if it works. my working N900 has a broken USB port, else I'd test for myself. others (Wizzup, etc. can also review). i can submit proper MR if it does work
<sicelo>
sure. as far as i understand it, we have this problem on N900 because 'full' status is fully under the control of the fuel gauage, and has very specific requirements that are difficult to meet with our present consumption pattern. i don't know if other devices are affected
duuude has joined #maemo-leste
<arno11>
is it working on D4 btw ?
<sicelo>
i think it does (because i seem to recall seeing the 'charge full. disconnect charger' message). of course d4 always has the green LED shining during charge, so you can't use that to tell
<arno11>
ok
<sicelo>
maybe i'll build this soon and share the deb ... now i'm itching to know if it solves the problem or not (naturally, i think it does)
<arno11>
ok (currently charging N900 + download and build upower)
<sicelo>
sure. you may want to kill upower afterwards so you're sure it's really running the new one
<arno11>
ok
ungeskriptet3 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 260 seconds]
ungeskriptet3 is now known as ungeskriptet
duuude has quit [Ping timeout: 256 seconds]
ungeskriptet3 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 268 seconds]
ungeskriptet3 is now known as ungeskriptet
ungeskriptet has quit [Client Quit]
ungeskriptet has joined #maemo-leste
<arno11>
sicelo: installing dependencies and build
<arno11>
*building
<arno11>
sicelo: what is the clean way to kill upower btw ?
<sicelo>
just pkill -f upowerd should be fine. it'll autostart
<arno11>
ah ok cool
<arno11>
(still installing dependencies, quite a lot)
<arno11>
building now
ungeskriptet6 has joined #maemo-leste
<arno11>
(battery @89% :P )
ungeskriptet has quit [Ping timeout: 246 seconds]
<sicelo>
oh lucky day, haha. you'll soon be at 100%
ungeskriptet6 has quit [Client Quit]
<sicelo>
or we might even have to set the trigger to slightly less ... i think i saw somewhere they do around 96-97%
ungeskriptet has joined #maemo-leste
ungeskriptet has quit [Client Quit]
diejuse has joined #maemo-leste
k1r1t0 has joined #maemo-leste
diejuse has quit [Client Quit]
Juest has joined #maemo-leste
<arno11>
sicelo: installing package(s)
<arno11>
arhg..killing upower crashed the device
<arno11>
booting
<sicelo>
ah, sorry :P
<arno11>
boot ok, let's go to 100%
stack_overflow has joined #maemo-leste
Juest has quit [Ping timeout: 252 seconds]
Juest has joined #maemo-leste
<arno11>
sicelo: got 'fully charged @96-97% :)
<sicelo>
really? green LED?
<arno11>
no green led, i'm waiting a bit
<sicelo>
what says fully charged?
<arno11>
the battery applet
<arno11>
now i'm @100%
<arno11>
1529/1529 (polarcell)
<sicelo>
green LED?
<sicelo>
btw charging full green led only appears when screen is off, iirc
<arno11>
still no green led and fully charged message disappeard @1528/1529 lol