<Wizzup>
well we can decide to bite the bullet if the 3d sitation is better, otherwise I don't feel like doing it yet
<Wizzup>
is gsettings and dconf available on beowulf then as well?
<freemangordon>
is port trivial?
<uvos>
port what?
<uvos>
away from gconf?
<freemangordon>
gconf->gsettings
<uvos>
no idea i havent done it
<Wizzup>
so what did you port them to, if not to gsettings?
<freemangordon>
"(18,16,30) uvos: so i have mce, osso-applet-display, osso-applet-notificationlight, simple-brightness-applet and maemo-input-sounds ported away from gconf" ?!?
<freemangordon>
yep, same question
<uvos>
ok so with mce i ported to expose its external iterfaces that it has on gconf to also have getter/setter/notify methods on dbus
<uvos>
then the mce faceing applets i ported to these dbus interfaces
<uvos>
mce also has selectable config backends so it can save to gconf of just a ini file with gsettings bein wip (havent finnished that yet)
<uvos>
and then osso-applet-displa also set on other gconf key
<uvos>
the one that tells maemo-input-sounds to vibrate the with touchscreen presses
<uvos>
this is also the only gconf key it uses, with everthing else, (ie if a sound is to be played when the ts is touched etc) it gets from libprofile
<Wizzup>
so the ui can't set a value unless mce is running?
<Wizzup>
or do I misunderstand
<Wizzup>
freemangordon: so uh, writing to the fb0/rotate doesn't do much with X running
<uvos>
so i just added a touchscreen.vibrattion.enabled key to profiled
<uvos>
and now that is profile dependant same as touchscreen.sounds.enabled
<uvos>
whitch makes more sense anyhow
<uvos>
Wizzup: yeah mce needs to be running for the ui to change the setting, but i dont see how thats a problem, gconf also had to be running and both of those are system global deamons
<Wizzup>
yes but gconf is the config management system
<Wizzup>
and for example settings keys in the ci when building images was already tricky
<Wizzup>
if it requires mce to run it will get a lot more tricky
<uvos>
the main benefit with this is that now all mce interfaces are on dbus so they are allways availbe and dont change when mce changes settings backend.
<uvos>
well mce still stores the stuff soemwhere
<uvos>
so in ci you can just chagne the gconf or gsettings key
<uvos>
i dont see the problem
<uvos>
or in the default ini file if you want to use the ini backend
<uvos>
but thats mainly intended to be a fallback
<Wizzup>
it just seems backwards to me that if an app wants to change a config key that it has to go through mce to set the config key, instead of mce listening to config key changes, I suppose
<Wizzup>
there is already a tool it needs to go through to changes, which is gconf/dconf iiuc
<uvos>
sortof
<uvos>
but if you look at the keys
<uvos>
only really the led ones are really config
<uvos>
its allso really backwards for the external application to request a change in lcd brightness by setting some config key
<uvos>
imo
<uvos>
and since the gconf interfaces are so few (only 3 unique ones)
<uvos>
it makes sense to just move everything to dbus
<uvos>
in this case
<uvos>
i do agree that moveing everything to dbus is not a solution in the general case
<uvos>
outside of mce
<uvos>
the main point here also is that mce can be used with different settings backends and its not ok that mce dependant applicaitons (also outside of maemo leste here) cant be sure that x interface will be available becasue the user decidede to use a different settings strorage backend
<Wizzup>
so in the current beowulf setup, the keys will just end up back in gconf, is that right?
<Wizzup>
via mce
inky_ has joined #maemo-leste
<uvos>
yeah both interfaces are allways kept in sync by mce
<uvos>
ie a dbus request to change the lcd brightness will cause mce to store this in gconf
<uvos>
(or in the ini file if you load that plugin instead)
<uvos>
and changing the gconf key with cause mce to notify its dbus clients of the change also
inky has quit [Ping timeout: 245 seconds]
<uvos>
i would like to know if there are any remaining qualms about how this works...
<Wizzup>
all my qualms currently are with this fbdev clone :)
<uvos>
btw we could also consider
<uvos>
instead of moving to gsetttings
<uvos>
to minimally extending profiled to also provide profile independant keys (or even just using the override profile) and porting everthing to that since this accives independance from gnome wimms and we are lugging profiled around as a settings deamon anyhow
<uvos>
libprofile and gconf are really close in terms of api too
<Wizzup>
I think many things should not go in libprofile
<Wizzup>
like when the email client last updated
<Wizzup>
just check how many gconf keys there are for modest alone
<uvos>
yeah i mean profiled would need a special overarching noprofile profile
<uvos>
other than that i dont see the problem really
<Wizzup>
I think it's not a bad idea to port to gsettings
<Wizzup>
actually, git reset --hard (save the config)
<Wizzup>
so I had this problem recently
<uvos>
or mrproper
<freemangordon>
I think I already did
<uvos>
it compiles fine for me
<Wizzup>
from old logs
<Wizzup>
18:23 < uvos> mrproper aka rebuild everything helped in these cases
<Wizzup>
18:23 < bencoh> yeah, mrproper is magic sometimes
<Wizzup>
18:24 < Wizzup> ok, trying
<Wizzup>
18:25 -!- Pali [~pali@user/pali] has joined #maemo-leste
<Wizzup>
18:28 < Wizzup> I mean I don't really need a new dtb anyway
<Wizzup>
18:30 < Wizzup> ah, no, it looks like the fdt.c errors are from the kernel needing libfdt to unpack the dts
<Wizzup>
18:31 < Wizzup> I'm using droid4-linux droid4-pending-pvr-omapdrm-v5.11
<Wizzup>
18:32 < Wizzup> internet suggests git clean -xdf
<Wizzup>
18:36 < Wizzup> that fixed it
<freemangordon>
ok, lemme try
<freemangordon>
ah, this is also known as -dfx :D
<Wizzup>
what's the joke?
<freemangordon>
Wizzup: no need to keep the config as I am using vanilla omap2plus_defconfig
<freemangordon>
Wizzup: I am using -dfx and was wondering what -xdf does
<Wizzup>
dfx is Don't FiX
<freemangordon>
or rather - I am used to -dfx
<freemangordon>
I see
<Wizzup>
(that was a joke)
<Wizzup>
(and not funny)
<freemangordon>
yeah
<Wizzup>
I try too hard
<uvos>
btw
<uvos>
charging light on n900 works again right?
<freemangordon>
ok, this time it compiles
<sicelo>
rgb led? i won't be surprised if it doesn't, because there are some issues with the lp55xx LED drivers. 'charging light' is h/w controlled, so that works at all times, unless i'm forgetting something
<uvos>
sicelo: this is about a spcific mce but i fixed
<uvos>
(and introduced in the first place)
<sicelo>
ok. no idea about *that*. if kernel driver doesn't work though ...
<uvos>
it works
<uvos>
(on 5.1)
<freemangordon>
hmm, latest u-boot should boot zImage, right?
<freemangordon>
*should be able to boot
<uvos>
theoreticly yeah
<uvos>
the new uboot that is
<uvos>
but i havent gotten it to work
<uvos>
but i also gave up almost immidatly
<freemangordon>
ok, will do with uImage
<freemangordon>
sicelo: hmm, with omap2plus_defconfig, shall I appned the dtb?
<sicelo>
yes, if you're using uImage
<freemangordon>
but, in kernel config this is not set. or, u-boot is smart enough?
* sicelo
has his fingers crossed that the N900 will boot fine (to a working display)
<freemangordon>
I doubt :)
<uvos>
i still find it kindof funny that the d4 with its locked bootloader ends up with more user frendly boot ergonimics
<sicelo>
freemangordon: the display is the most annoying part of booting a new kernel on N900. (i still need to build my console thingy for N900)
<freemangordon>
and... poweroff
<uvos>
mh
<uvos>
you have the debugkit right
<freemangordon>
no
<uvos>
hmm
<uvos>
great
<sicelo>
oh :-) i don't recall facing that one, but then, i haven't been building N900 kernels for too long
<freemangordon>
yeah :)
<freemangordon>
(debugkit)
<Wizzup>
uvos: latest u-boot for n900? the one I built should work fine?
<Wizzup>
uvos: yes, the mce fix worked for charging light
<freemangordon>
hmm, it has usb console
<sicelo>
i didn't find the uboot console super useful, since kernel disables it once it starts. and the problems are in the kernel. maybe there's a way to ask kernel to not disable it?
<Wizzup>
it is useful for testing / remote stuff
<Wizzup>
compared to typing on that keyboard... ugh
<Wizzup>
I mean I like the keyboard, but not in u-boot :)
<sicelo>
yeah
<sicelo>
it's just that most of the time, the real problems are in the kernel, not uboot :-(
<sicelo>
maybe we really should check if there's no way to have that console persist
<freemangordon>
ok, as expected, omap2plus_defconfig doesn;t boot
<freemangordon>
if anyone has a working config around, please share
<sicelo>
make the watchdog built in. that's one change i usually make to omap2plus
<sicelo>
+CONFIG_OMAP_WATCHDOG=y
<sicelo>
+CONFIG_TWL4030_WATCHDOG=y
<freemangordon>
I am trying leste config ATM
<sicelo>
we should get you its serial console - i want to build one (based on sre's design), but i don't know if i'll be able to understand issues it reports. at least you would
<freemangordon>
do you have the schematics around?
<freemangordon>
or, are those available to buy online?