<vectis>
Douh yeah, sorry for asking. It's been a long time since I tried any of this.
<Wizzup>
vectis: not sure why it doesn't work by default
ruleh has quit [Ping timeout: 256 seconds]
<bencoh>
Wizzup: probably because osso-xterm spawns a login shell instead of a regular one
<vectis>
So I have compiled evilvte (terminal emulator) for droid4 and it works, but the caps seem to be on by default. I can get lower case by pressing caps, but I have to do this for every letter.
<Wizzup>
that seems odd?
<vectis>
Yep, no issue in osso-xterm
<vectis>
I've used evilvte for many years on my collection of n810's and thought it would transfer OK over to Leste
ruleh has joined #maemo-leste
<Wizzup>
vectis: is it gtk2?
<vectis>
Yes, appears so (libgtk-x11-2.0.so.0)
<Wizzup>
so hildon input method should work mostly
<vectis>
Ermm, does this mean it doesn't in this case?
<Wizzup>
well, I haven't heard of any application doing caps
<Wizzup>
in this way
* Wizzup
zz
<vectis>
Perhaps I am not explaining it right. Every letter I type is upper case unless I hit "caps" first, but it doesn't stick (I have to do this every time)
<vectis>
Time for sleep here as well. Could you try evilvte yourself at sometime?
<vectis>
It's a small binary.
cockroach has quit [Quit: leaving]
Pali has quit [Ping timeout: 268 seconds]
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
<sicelo>
i probably should scour the logs, but how to get the latest updates on d4? (new mesa, kernel, pvr, etc.)
<sicelo>
i'm on -devel and a simple apt upgrade didn't pull those in, afaict
<Wizzup>
it is in -experimental and we o not have a migration path yet
<Wizzup>
parazyd said he didn't know how to make it work with just update
<Wizzup>
I might try again today
<Wizzup>
sicelo: help appreciated btw
<sicelo>
mmm, it didn't quite work fully for me :-)
<sicelo>
in dmesg, grepping for 'ddk' returns nothing. iirc that should return something,
<Wizzup>
sicelo: what we want is to make sure 'apt upgrade' on -experimental just pulls in all the new stuff
<Wizzup>
but for example cloudgps depends on some sgx package quite directly
<Wizzup>
so we need 'provide' those
<Wizzup>
I suggested to parazyd to depend on *everything* we need in hildon-droid4-meta as a test
<sicelo>
interestingly, that's not installed on my d4 (hildon-droid4-meta). is it new?
<Wizzup>
maybe it's hildon-meta-droid4
<sicelo>
yes, the package is hildon-meta-droid4, but it's not installed on my d4. also trying to install it now fails with
<sicelo>
The following packages have unmet dependencies: hildon-meta-droid4 : Depends: hildon-meta but it is not going to be installed
Pali has joined #maemo-leste
<sicelo>
but hildon-meta is installed.
<Wizzup>
sicelo: weird, I have it I think
<Wizzup>
let me debug a bit later today, I have another droid4 here
<Wizzup>
I will bring it up to date with -devel and then see if I can make it 'just upgrade' to -experimental stuff
<freemangordon>
Wizzup: if you have d4 with ddk 1.9 around, could you please enable video-omap debug and provide Xorg.log (after some scroll in h-d)
<freemangordon>
no hurry though
<freemangordon>
also, if possible, start h-d from shell with CLUTTER_SHOW_FPS=1 env var set, and provide max fps h-d scrolls with
<sicelo>
Wizzup: getting weirder,
<sicelo>
hildon-connectivity-wlan : Depends: libicd-network-wpasupplicant-dbus-n900 but it is not installable or
<sicelo>
libicd-network-wpasupplicant-dbus-common but it is not installable
_inky has quit [Ping timeout: 245 seconds]
<Wizzup>
freemangordon: can you provide specific instructions?
<Wizzup>
sicelo: this shouldn't happen after apt upgrade
<Wizzup>
I don't think it is right that the mapphone-common dtsi assumes the ram to be 1021MB
<Wizzup>
should I send a rfc patch to linux-omap perhaps?
inky has quit [Ping timeout: 256 seconds]
_inky has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
Danct12 has joined #maemo-leste
Danct12 has quit [Client Quit]
Danct12 has joined #maemo-leste
_inky has joined #maemo-leste
Daanct12 has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 268 seconds]
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 256 seconds]
Daaanct12 has quit [Ping timeout: 268 seconds]
akossh has joined #maemo-leste
pere has quit [Ping timeout: 245 seconds]
uvos has joined #maemo-leste
<uvos>
Wizzup: you can just overwrite the nodes in your dts
<uvos>
for xt86x
<uvos>
but yeah we need to think more about how to struture this
<uvos>
lots of stuff needs to go for xt86x
<uvos>
touchscreen-buttons etc
<Wizzup>
uvos: ok, I'll start with that for my unified build
<Wizzup>
let me try that now in fact
<uvos>
gets even worse with mz6xx
<Wizzup>
yeah, I think it might not be super hard/annoying really, we just need to decide
<uvos>
memory node lacks a lable
<uvos>
btw
<uvos>
so you cant override
<uvos>
it
<Wizzup>
right, I think that's why I did it there
<uvos>
just add one
<uvos>
dsi allready has one so thats fine
<Wizzup>
uvos: so I do that by adding memory0: in front of it?
<uvos>
shoud work yeah
<uvos>
Wizzup: wrt the logs
<uvos>
Wizzup: that setup looks fine
<uvos>
Wizzup: but we need to rotate more often
<Wizzup>
yes, but the majority of log spam is (1) debug statements in connui-cellular and (2) ke-recv usb on mapphones
<Wizzup>
we just need to fix that
<uvos>
whats ke-recv logging?
<Wizzup>
usb bouncing
<uvos>
that often?
<uvos>
ok
<uvos>
what about ofonod.log?
<Wizzup>
sure, if it is fully charged it happens every few seconds
<uvos>
and h-s-m
<Wizzup>
ofonod.log is large because I run it with debug from /etc/init.d
<uvos>
both of those seam also pretty insane
<uvos>
ok
<uvos>
i gues one problem with h-s-m is that any plugin can cause it to log lots of glib-critical
<Wizzup>
sorry, what is h-s-m?
<uvos>
61M Nov 28 16:31 hildon-status-menu.log
<Wizzup>
yeah
<Wizzup>
well, the point of splitting this out is precisely to find those problems
<uvos>
it might make sense to slowly port some of the plugins to StatusNotifierItems to make h-s-m more robust. any of the plugins thats just a button an icon and 2 lines of text (one white one blue) might as well be a StatusNotifierItem, that way it cant crash h-s-m or cause it to missbehave and the plugin in question can also be used in other enviornments than hildon
<uvos>
but the chance of geting the last lines is pretty low
<uvos>
that way
<Wizzup>
yes, we need a proper way to attach serial when idle..
<uvos>
looks sane @dts
<Wizzup>
on status menu and notifiers, I haven't really looked at all yet, sorry
<Wizzup>
I will try to later, but my mind is on getting n900/d4/etc on same kernel and new 3d in place and packaged in -devel, and then this tp stuff
<uvos>
yeah no worrys
<Wizzup>
I was hoping to use the n900 modem because ofono is more stable there, but of course the nokia-modem has dma problems now :D
<uvos>
yeah
<uvos>
anyhow wrt the status-menu i just think having the status menu items in seperate proceies via the xdg interface makes more sense than having them as plugins in a single process from a robustness perspective
<uvos>
ofc this will use a bit more ram
<uvos>
so idk, depends on how mutch we want to hold onto the n900 in the long run.
<Wizzup>
probably true, we'll have to evaluate and depends on n900 ... yeah
* Wizzup
mumbles something about prying the n900 from his cold dead hands :P
<uvos>
:P
<sicelo>
what's the context of n900 relevance? ofono? status menu?
<uvos>
sicelo: using more ram in the name of robustness
<uvos>
sicelo: in this case making things like hildon-status-menu and -home use seperate processies
<sicelo>
ok
<uvos>
so that one application crashing dosent bring down the whole thing
<uvos>
s/application/plugin
<Wizzup>
uvos: I don't know if you see this but to me the d3 doesn't connect/disconnect as much when it is fully charged
<Wizzup>
maybe just a different (battery) limit or something, not sure
<uvos>
Wizzup: same with bionic
<Wizzup>
yeah
<uvos>
no idea why
<uvos>
the d4's rails are really noisy
<uvos>
that might affect the adc
<uvos>
the d4 is electricly just a bit marginal maybe
<uvos>
or its st vs on semi manufactured cpcap variants
<uvos>
maybe one of those works better
<Wizzup>
mhm
* Wizzup
hoping this kernel will boot on his d3
<Wizzup>
of course it doesn't have the older ddk, so it won't boot to X probably, but hey :)
<uvos>
qrc:/qml/BrowserWindow.qml:34:1: module "QtQuick.Controls.Styles" is not installed
* uvos
sigh
<Wizzup>
hehe
<uvos>
on the brigt side qtwebrowser is reaaly nice on bionic
<uvos>
for some reason bionic still seams more fluid than d4
<uvos>
probubly its dsi droping frames in d4
<Wizzup>
[ 0.303497] cpuidle: using governor menu
<Wizzup>
[ 0.345520] hw-breakpoint: Failed to enable monitor mode on CPU 0.
<Wizzup>
[ 0.343139] No ATAGs?
<Wizzup>
:(
<Wizzup>
(droid3 not booting)
<Wizzup>
maybe the bootcfg is wrong, let me check...
<Wizzup>
Broken xserver-xorg-video-omap:armhf Depends on sgx-ddk-um-libs:armhf < none @un H > Considering sgx-ddk-um-ti443x:armhf -2 as a solution to xserver-xorg-video-omap:armhf 0 Holding Back xserver-xorg-video-omap:armhf rather than change sgx-ddk-um-libs:armhf
<Wizzup>
ah;
<Wizzup>
Broken sgx-ddk-um-ti443x:armhf Conflicts on libegl1-sgx-omap4:armhf < 1.9.0.8.1.3-1+2m7.4 @ii mK > Considering libegl1-sgx-omap4:armhf -1 as a solution to sgx-ddk-um-ti443x:armhf -2 Holding Back sgx-ddk-um-ti443x:armhf rather than change libegl1-sgx-omap4:armhf