atk has quit [Quit: Well this is unexpected.]
atk has joined #maemo-leste
mrgeanie has quit [Quit: Ping timeout (120 seconds)]
mrgeanie has joined #maemo-leste
Oksana has quit [Ping timeout: 246 seconds]
Oksana has joined #maemo-leste
lyubov has joined #maemo-leste
kvw_5 has quit [Ping timeout: 252 seconds]
kvw_5 has joined #maemo-leste
diejuse1 has quit [Quit: Leaving.]
The_Niz has quit [Ping timeout: 258 seconds]
The_Niz has joined #maemo-leste
pagurus has quit [Ping timeout: 265 seconds]
mardy has joined #maemo-leste
<freemangordon> Wizzup: in general I am against mixing build systems unless no option (qmake for example), not sure what to say about mce...
Pali has joined #maemo-leste
<freemangordon> re icd2 - maybe ask on #maemo, I am not aware of any use of this API
<freemangordon> but in general it should work
<parazyd> freemangordon: We haven't really found any programs that use it so far
<parazyd> uvos: So you're saying we should compile our sdl1.2 with those flags?
<parazyd> (We already do have our own)
jonsger has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> parazyd: yes we should
<Wizzup> uvos: great work, looks like we maybe need to fix the xinerama mode checking
<uvos> parazyd: and also drop all maemo patches for now
<uvos> Wizzup: no xinerama mode checking is fine
<uvos> Wizzup: the sdl code is fine
<uvos> Wizzup: just so outdated that it breaks with rotation
<Wizzup> hmm
<uvos> -enable-video-x11-xinerama=yes --enable-video-x11-vm=no
<uvos> probubly also works
<uvos> i just want it to use legacy randr 1.0 instead of xinerama because that is more modern
<uvos> just xvidmode dosent work
<uvos> but it cant
<uvos> xvidmode speifys the real framebuffer geometryt
<uvos> that is not rotated with randr
<uvos> so no way this will ever work
<parazyd> Awesome
<uvos> just configure sdl1.2 to use randr as above
<uvos> and everything works
<uvos> there is no bug
<Wizzup> ok, I'll give it some checks locally, great work
<Wizzup> I never even heard of xvidmode
xmn has quit [Quit: ZZZzzz…]
<uvos> Wizzup: its a realy old x extension
<Entitlement> uvos - [ xf86vidmodegetallmodelines(3) - Linux man page ]
<kek> parazyd transferred a repository: https://github.com/maemo-leste-upstream-forks/libsdl1.2
<uvos> it querys real video mode lines
<parazyd> So our patches are the first 6 (starting with 3x0_) https://github.com/maemo-leste-upstream-forks/libsdl1.2/tree/master/debian/patches
<Entitlement> parazyd - [ libsdl1.2/debian/patches at master · maemo-leste-upstream-forks/libsdl1.2 · GitH... ]
<uvos> as they are scanned out to display
<parazyd> What about this pulseaudio patch?
<Entitlement> parazyd - [ libsdl1.2/330_pulseaudio_tease.diff at master · maemo-leste-upstream-forks/libsd... ]
<uvos> no idea
<uvos> audio works fine in brainparty in upstream sdl1.2
<uvos> so i would just drop it
<parazyd> ok. I'll compile this for -devel then and we can play with it.
<uvos> parazyd: maybe just sync with https://github.com/libsdl-org/SDL-1.2/commits/main
<Entitlement> uvos - [ Commits · libsdl-org/SDL-1.2 · GitHub ]
<uvos> as this also has had some other fixes beside the ones in patches
<uvos> incl security stuff
<uvos> as recent as this month
<uvos> *last
<parazyd> ok let me check debian because we track from salsa
<Wizzup> uvos: what about that grab thing?
<Wizzup> I think it's a patch to ignore grabnotify's or something
<uvos> Wizzup: sdl1.2 creates a override redirect window
<uvos> Wizzup: per x spec it _MUST_ grab the keyboard and dose
<uvos> now there is some merrit to patiching it to be a NET_WM_FULLSCREEN window
<uvos> instead
<uvos> and let hildon give it focus
<uvos> but lets worry about that some other time
<uvos> stock sld behavior works as intended
<Wizzup> ok
<uvos> the down side ofc is that right now a sdl client will lock out any hildon shortcuts
<uvos> incl the mapphone buttons and volume
<uvos> the way the maemo patches hack around this is not the way to go tho
diejuse1 has joined #maemo-leste
<Wizzup> uvos: yes, but that is a problem since I often use the power button menu to kill apps
<Wizzup> without that, sdl clients can just 'take over'
<Wizzup> and there is no way to kill them
<uvos> thats correct
diejuse1 has quit [Client Quit]
<uvos> to fix this you need to make sdl ewmh aware
<uvos> a non trivial task
<Entitlement> uvos - [ libsdl1.2/320_no_fullscreen_grab.diff at master · maemo-leste-upstream-forks/lib... ]
<uvos> dose is just plain wrong
<uvos> then you have a overide_redirect window that excpects the wm to give it focus
<Entitlement> uvos - [ libsdl1.2/340_fs_notor.diff at master · maemo-leste-upstream-forks/libsdl1.2 · G... ]
<uvos> hmm
<uvos> maybe its not so bad
diejuse1 has joined #maemo-leste
<Wizzup> we'll try it, I'm waiting for parazyd to build the unpatched one first
<Wizzup> so we can test stuff :)
<Wizzup> I'll get on scummvm as well
<uvos> btw the mouse was wierd because of xfree86-dga
<uvos> the dga extension has a mode where you can get the physical mouse data as if your listening to a serial mouse
<uvos> obviously this makes no sense on a ts
<uvos> i seams that Xinput makes an effort to emulate this
<uvos> but its buggy somehow
<uvos> sdl 1.2 really diggs up the most crusty of x extensions :P
<Wizzup> maybe we need to disable that as well
<uvos> yes see above --enable-dga=no
<uvos> we might want to disable the extension in X
<uvos> aswel
<uvos> so no other applicaiton tyes to use it
jonsger has quit [Ping timeout: 240 seconds]
<Entitlement> parazyd - [ Force legacy randr via confflags. · maemo-leste-upstream-forks/libsdl1.2@ef2060f... ]
<parazyd> Building now
<Wizzup> uvos: right @ in X
<uvos> byw sdl1.2 dosent support multi pointer
<uvos> so it will inevtably loose touch events on d4
<Wizzup> yeah, we'll recommend people to port to sdl2 :)
<Wizzup> but having it at least work is helpful
<Wizzup> uvos: cool, brainparty and cloudgps start on my d4
<Wizzup> they don't use the entire screen in fullscreen, but I think that's to be expected since these things often have hardcoded window sizes
<uvos> cloudgps should work fine
<uvos> brainparty hardcodes a size
diejuse1 has quit [Quit: Leaving.]
<uvos> and sdl is supposed to put it in the middle
<Wizzup> cloudgps did too, let me pull latest code
<parazyd> Wizzup: Built sdl1.2, package version should have a +leste1 extension
<Wizzup> iirc I fixed
<Wizzup> parazyd: I think we're testing it already :p
<uvos> it works with the test app
<uvos> but brainparty ends up off center for some reason
<Wizzup> uvos: yeah, and it doesn't start an actual test (I think it crashes)
<Wizzup> should try drnoksnes and stuff :)
<uvos> Wizzup: works for me
<Wizzup> uvos: d4?
<uvos> yes
<Wizzup> interesting
<Wizzup> I'll run it from cmdline in a bit
<uvos> works from the icon
<uvos> btw
<Wizzup> uvos: I think I'll try with the fs_notor patch a bit later today
<uvos> if you update brainparty
<Wizzup> just to see if it helps
<uvos> no
<uvos> input cant work if you do this
<uvos> pls fix brainparty packaging
<uvos> shoving the binary into opt is not the way
<Wizzup> yeah, that was done in fremantle everywher
<Wizzup> I removed it for most
<Wizzup> maybe I forgot here
<Wizzup> uvos: yeah pulling in my own latest code makes cloudgps work :p
<Wizzup> I'll add it to -extras today
<Wizzup> (or did I do it already, I forgot)
<uvos> i used it from repo so yes
<uvos> and it works fine
<uvos> (version in repo)
<uvos> with patched sdl ist mutch faster
<uvos> 70 vs 30 fps
diejuse1 has joined #maemo-leste
<uvos> this is because hildon fails to unridirect the window
<Wizzup> I think it disabled compositing
<Wizzup> yes
<uvos> it should just do that for fullscreen overruide redirect windows
<Wizzup> do you want to patch h-d for that?
<uvos> yes this is hildons problem
diejuse1 has quit [Client Quit]
<uvos> it can just suspend whenever a fs app is on top
<Wizzup> what about making a window unfullscreen and showing the app mgr?
<Wizzup> I guess that should work since the window is made un-fullscreen
<uvos> yes works automaticly
<Wizzup> uvos: does the button to go to the task manager work for you in cloudgps?
<uvos> also showing a notification banner immidatly resumes
<uvos> Wizzup: yes
<uvos> Wizzup: but the window is in windowed mode after that
<Wizzup> weird, for me neither that nor the 'X' work
<uvos> Wizzup: whitch is somehting sdl dose
<Wizzup> now it worked
<Wizzup> what if you do 'p' twice in keyboard?
<Wizzup> uvos: hm, when it worked, and I went back to the app, it went back in fullscreen, so I am seeing different things from you
<uvos> pressing p works fine
<uvos> but an app rotating itself is evil
<Wizzup> hm
<Wizzup> well the app not wanting to exit in combination with those power keys not working is a problem
diejuse1 has joined #maemo-leste
<uvos> yeah that was terrible on desktop too
<uvos> back in sdl1.2 land
<Wizzup> this isn't fixed in libsdl2 though is it?
<uvos> yes it is
<uvos> sdl2 is a normal ewmh citizen
<Wizzup> ok
<Wizzup> parazyd: you also set enable-video-x11-xv=no - I am not sure if it matters, but iirc we'd probably want to keep that?
<Wizzup> not that we do xv atm :)
<Wizzup> uvos: ok, hrm
<parazyd> 01:25 <uvos> you can force it to use legacy randr by compiling with "./configure --enable-video-x11-xrandr=yes --enable-video-x11-xinerama=no --enable-video-x11-vm=no --enable-dga=no --enable-video-x11-xv=no --enable-video-x11-dgamouse=no
<parazyd> Followed this
<parazyd> but ok
<uvos> Wizzup: it was spitting a warning
<parazyd> Wizzup: If you can, test SDL on the Pinephone
<uvos> so i removed it
<uvos> but it should work ok if you enable it
<uvos> was maybe a bit overzealus
<Wizzup> parazyd: btw, any reason we can't run gpsd as user?
<parazyd> Yeah it simply doesn't work
<Wizzup> so if the kernel gps files are user:users, it doesn't work?
<uvos> they are 444 rn
<uvos> so no
<parazyd> per Gary, loosely quoted: "Various weird bugs will occur if gpsd doesn't start as root. gpsd drops its privileges ASAP"
<Wizzup> ah, ok
<Wizzup> that's fine then
<Wizzup> uvos: you said you installed cloudgps from extras? my pinephone doesn't show it, weird
<uvos> none of the other tilesets work in cloudgps :(
<uvos> Wizzup: you put it into extras-devel
<Wizzup> ah, I forgot that worked
<Wizzup> :D
<uvos> which is somehting you should avoid
<Wizzup> why
<uvos> it makes no sense
<Wizzup> I think it does, if I want to test cloudgps builds without sending them to everyone
diejuse1 has quit [Ping timeout: 260 seconds]
<uvos> ok
<Wizzup> for example the current cloudgps with libsdl will make it impossible for a user to kill it unless they know the magic key combination 'q'
<uvos> well i dont think you should be testing it in the repo then
<Wizzup> which also requires a physical keyboard
<uvos> but im not terribly concerned
<uvos> since no one has extras-devel enabled anyhow
<Wizzup> do you have the source.list line for extras-devel?
<uvos> deb https://maedevu.maemo.org/extras beowulf-devel main contrib non-free
<Wizzup> it's not this, iiuc: deb https://maedevu.maemo.org/extras beowulf-devel main contrib non-free
<Entitlement> uvos - [ Directory Index - Maemo Leste ]
<uvos> no that is is
<uvos> works for me
<Wizzup> well then apt is lying to me about cloudgps not being in there
<uvos> upps
<uvos> my bad
<Wizzup> it's not in the repo huh? :p
<uvos> its not
<uvos> sorry
<Wizzup> np
<Wizzup> ok, I will test on pinephone in a bit parazyd
<uvos> can you check a new image too
<Wizzup> sure
<uvos> as inky claims it dosent work for ratation
<uvos> rotation
<Wizzup> in a bit though
<uvos> can we maybe sponsor parazyd a new pp?
<Wizzup> I think that should be np
<uvos> i think just you having one is intollerable if we want to claim to support it
<parazyd> I can get one, it's np
<uvos> ok
<parazyd> Just waiting for the hw keyboard situation
<uvos> ok
<parazyd> So I'd try to get that all at once
<Wizzup> Might take a while though
<uvos> dose the devkit still work?
<Wizzup> I have one iirc (devkit)
<Wizzup> So with my lab psus I could set up some CI maybe, but I am a bit worried leaving them on all the time when I am not home
<parazyd> I have Wizzup the sopine module :p
<uvos> why
<Wizzup> I have three, one for each phone (n900,d4,pinephone)
<Wizzup> uvos: not sure, maybe I just need reassurance :p
<uvos> whay are you afaid will happen? just set the current limmit to something reasonable
<Wizzup> mhm
<uvos> worst case the device dies
<Wizzup> parazyd: I think it might take a while for the keyboard to arrive, maybe just get the addon later?
<Wizzup> brainparty is just a black screen on the pp
<Wizzup> started it again, now it's ok
<Wizzup> could be a lima thing
<uvos> lima maby
<uvos> *maybe
<Wizzup> input is weird/flakey
<parazyd> PINEPHONE – Beta Edition Linux SmartPhone × 1
<parazyd> Thank you. Your order has been received.
<Wizzup> well on brainparty at least
<parazyd> Lp
<parazyd> :p
<Wizzup> let me try some other apps in a bit
<Wizzup> I think brainparty is not the best test app since it was specifically adapted for the n900 screen and such
<uvos> Wizzup: it works fine for me
<uvos> Wizzup: what do you mean flaky
<Wizzup> uvos: this is pinephone
<uvos> oh ok
<uvos> maybe pinephones touch driver reports touches on slots 2-10 often
<Wizzup> uvos: now on d4 it's ok for me too, btw
diejuse1 has joined #maemo-leste
<uvos> then it wont work randomly
<Wizzup> just needs scaling :)
<uvos> as sdl will only respond to slot
<uvos> 1
<uvos> maybe try brainpary on n900
<uvos> mine is empty
<uvos> rn
<Wizzup> ok, yeah, I
<Wizzup> I'll boot it
<Wizzup> brb though
diejuse1 has quit [Quit: Leaving.]
diejuse1 has joined #maemo-leste
<Wizzup> upgrading n900 :)
<Wizzup> it rebooted because of ke-recv
<Wizzup> ..
<diejuse1> parazyd uploaded a video? what is the link?
<Wizzup> looks like the reboot caused the device to also not start icd2 and other things :/
<parazyd> diejuse1: No, it was some sxmo video
R0b0t1 has quit [Ping timeout: 240 seconds]
<parazyd> Wizzup: Dies "apt -f install" try to do anything now?
<Wizzup> I have to sudo dpkg --configure -a
<Wizzup> but wifi is broken
<Wizzup> so it's all kinda tricky
<Wizzup> I guess I got lucky it didn't break X
<uvos> lets just disable lifeguard for now....
<uvos> its mostly just annoying
<Wizzup> Are you sure this is the lg?
<parazyd> Yeah, probably
<parazyd> Also nothing really changed in ke-recv recently, so I'm pretty sure this was always around
<parazyd> "nothing really changed" I mean regarding init
<Wizzup> isn't that a dsme thing?
<parazyd> The initscript uses dsmetool
<uvos> lifeguard and apt also just fundamentaly dont mix
<uvos> if any upgraded deamon that lifeguard checks dosent start after upgrade
<parazyd> This is true
<uvos> lifeguard procedes to render the device unbootable
<uvos> by crashing apt
<uvos> great
<Wizzup> I'd like to verify this is the case thugh
<parazyd> The lifeguard is more a lockdown than useful IMHO
<Wizzup> err what
<Wizzup> Maybe I fundamentally don't understand what it does
<uvos> +1
<uvos> not the resapawn deamon part
<parazyd> One part reboots the device if services crash
<uvos> but the reboot device if respawn fails
<parazyd> Giving you no way to debug the issue, only post-mortem
<uvos> but the respwan deamon part can be replaced by supervise deamon
<uvos> so lifeguard is mostly just annoying
<Wizzup> Isn't this a dsme feature?
<uvos> yes
<uvos> this dsme module is called lifeguard
<Wizzup> also I am pretty sure on most of my devices I have touched that file
<Wizzup> and I think they still all rebooted
<Wizzup> so it might be something else
<Wizzup> afaik lifeguard at least would write some info about that happening, and not do a hard reset
<Wizzup> it all looks like hard reset really
<uvos> ok
<Wizzup> the ssh conn doesn't get killed
<Wizzup> it just hangs
<Wizzup> this was true for all the devices I did this on
<uvos> none of my devices misbehaved btw
<Wizzup> it was n900, droid4, droid4, pinephone here :p
<uvos> that makes a hard reset kinda unlikely
<uvos> since they run pretty different kernels
<Wizzup> not if it's lifeguard though?
<uvos> sure lifeguard reboots any device :P
<Wizzup> uvos: sorry, I meant watchdog
<uvos> also via the watchdog interface
<uvos> yeah lifeguard misbehaving can cause the kernel to watchdog reboot
<uvos> because it drives the interface
<uvos> again lifeguard is makeing things worse...
<uvos> lifeguard causing a watchdog reboot is particually annoing since its almost impossible to tell if that is what happend.
<uvos> i think you should get something in pstore if you have it
<Wizzup> it should not cause a watchdog reboot if the watchdog is released properly and kernel tgakes over
<Wizzup> iiuc
<uvos> right
<uvos> "lifeguard misbehaving"
<Wizzup> maybe. :)
<Wizzup> would be nice if we know what triggers it, then I can debug
<uvos> no doubt
<uvos> " if any upgraded deamon that lifeguard checks dosent start after upgrade lifeguard procedes to render the device unbootable by crashing apt before the upgrade finishes"
<uvos> thas a problem regardless of the current cause of reboot
<freemangordon> uvos: you have records in syslog
<Wizzup> this is true for a small subset of services, so it would be good to check
<freemangordon> on lifeguard reboot that is
<uvos> Wizzup: i mean its true of any device
<uvos> Wizzup: lifeguard can break X like this
<Wizzup> I think this is the relevant part:
<uvos> Wizzup: and then lifeguard will bootloop endlessly because x wont start
<Wizzup> May 17 12:09:30 localhost DSME: removed exited process (pid 2461) from process wd
<Wizzup> May 17 12:09:31 localhost waitdbus[11505]: trying to connect to the system bus
<Wizzup> May 17 12:09:31 localhost waitdbus[11506]: trying to connect to the session bus
<Wizzup> May 17 12:09:31 localhost DSME: process '/sbin/mce --force-syslog' started with pid 11508
<Wizzup> May 17 12:09:31 localhost systemui-powerkeymenu[2558]: systemui: shutdown_ind from DSME, quitting
<Wizzup> May 17 12:09:31 localhost DSME: new state: DSME_STATE_REBOOT
<Wizzup> so it is maybe a dsme restart?
<freemangordon> also, watchdog is opened with "no disable on close" option, IIRC, so if dsme crashes, it will reboot the device
<freemangordon> Wizzup: or rather someone told dsme to restart
<Wizzup> freemangordon: yes, apt
<Wizzup> uvos: in any case, latest libsdl1.2 from our repo works with brainparty on the n900
<freemangordon> ok, maybe I am missing the issue here
<uvos> freemangordon: we are discussing 2 issues
<Wizzup> freemangordon: it's not clear yet, but there is a one time upgrade that will reboot for sure during upgrade, at least on my devices
<uvos> freemangordon: 1 apt upgrade has been rebooting devices
<freemangordon> hmm, I think I just saw that in the VM
<uvos> freemangordon: and 2 dsme lifeguard will break installes by crashing apt when it reboots if the upgrade has any deamon not start for any reason
<uvos> leaving apt packages unconfigured
<freemangordon> that's why we shall not upgrade with apt, but with HAM ;)
<Wizzup> uvos: the scummvm menu behaves a bit weird, first relative mouse (vm) works, then when I click 'add game', there is a dialog, cancelling the dialog makes relative mouse no longer work
<Wizzup> could be scummvm git issue
<uvos> freemangordon: sorry thats not a realy a good solution..
<Wizzup> or qemu, disregard for now
<freemangordon> because HAM has special mode for system upgrades
<freemangordon> uvos: why?
<Wizzup> I think it'd be better to figure out what's up for now
<Wizzup> HAM can't even do system upgrades
<freemangordon> CSSU's been using it for years
<Wizzup> and it'd be nice if we can make normal devuan 'just work' as much as possible
<uvos> and even if it could we should not break apt
<Wizzup> yes, but we don't even know what classifies as system upgrade here
<freemangordon> any service/library upgrade is a system upgare
<freemangordon> *upgrade
<freemangordon> we're not running servers here, so restarting on upgrade is not an issue
<freemangordon> Wizzup: BTW, system packaes are marked as such in debian/contro
<freemangordon> *control
diejuse1 has quit [Quit: Leaving.]
<freemangordon> also, once we have a stable system, I don;t see a reason why not doing it like we did, by using system upgrade metapackages
<freemangordon> we == CSSU
<Wizzup> ok, so git scummvm does work, but uses gtk3 for the dialogs (not ideal)
<Wizzup> freemangordon: I think uvos just wants lifeguard disabled for now
<Wizzup> freemangordon: good to know @ system packages
<Wizzup> cc parazyd ^
<Wizzup> uvos: scummvm works in vm with libsdl, but now being able to use power menu I think is still a problem
<parazyd> This is not something we can rely on really, unless you consider system packages being all packages without "user/*" section
<Wizzup> or maybe it does work
<Wizzup> parazyd: this is about maemo system packages I think
<freemangordon> ok, please disable it on the images by creating that special file, do not remove/change any code
<freemangordon> parazyd: so?
<freemangordon> what is the problem, please explain
<parazyd> We walso want people to get updates for openssl, dbus, etc.
<freemangordon> they will
<freemangordon> HAM is capable of updating them
<Wizzup> parazyd: the point was that if we upgrade one of those packages, we can enter 'system upgrade mode' in HAM
<parazyd> I know the magic package, yes.
<freemangordon> :nod:
<Wizzup> it wasn't about showing them all or something
<parazyd> 12:56 <Wizzup> parazyd: this is about maemo system packages I think
<parazyd> I was talking about this.
<freemangordon> have to attend work mtg, bbl
<Wizzup> uvos: ok, so power menu still works on BP and scummvm on n900 and vm, so maybe that's fine
<uvos> Wizzup: power menu should work everywhere
<uvos> Wizzup: acctually
<uvos> since its triggerd by mce
<uvos> and mce gets the input from kernel directly
<uvos> and so the x11 grab dosent apply
<uvos> hildon-shortcuts dont wokr
<uvos> yeah works fine on d4 cloudgps
<uvos> i forgot that powerkey is not transmitted though x
<Wizzup> check
<uvos> any remaining reason not to just leave sdl1.2 like this (unpached) now?
<Wizzup> mostly not, I've found in a few places that the button to go hildon doesn't work
<Wizzup> but otherwise, pretty happy with this
<Wizzup> I am going to get cloudgps and fixed scummvm in extras
<Wizzup> maybe we can think of a few more things to test with
diejuse1 has joined #maemo-leste
<uvos> i mean it would be nice if the mapphone buttons worked
<uvos> also how dose tklock fare
<uvos> it really should not open at all if another client has exclusive keyboard grab
<uvos> but it probubly dose right now
<uvos> i dont use tklock so cant check
<Wizzup> so just open a program, try to lock, etc?
<uvos> yeah open cloudgps
<uvos> and lock the device with it fullscreen
<Wizzup> yeah tklock is broken
<uvos> yeah ok
<Wizzup> heavily broken
<uvos> tklock needs to 1. hold a keyboard grab
<uvos> and 2. not open if it cant
<Wizzup> device is rebooting :)
<uvos> thats how every other x11 lockscreen works
<Wizzup> uvos: so how do I lock the phone (which I do want to) with cloudgps open?
<uvos> Wizzup: you cant if its fullscreen
<uvos> Wizzup: fundamental x limitation
<Wizzup> maybe this is why there are the fremantle patches then
<Entitlement> uvos - [ Why screen lockers on X11 cannot be secure – Martin's Blog ]
<uvos> Wizzup: no the real reason they did what they did with the patches
<uvos> Wizzup: is that hildon desktop used to break with fullscreen override redirect windows
<uvos> as is evidenced in hildon-desktop comments
<Wizzup> but lock screen works in fremantle even with full screen sdl windows I think
<Wizzup> maybe it's because they mess with the input grab
<Wizzup> also, my d4 didn't reboot, because it has the no lg file, so we can rule out that that caused the reboots
<uvos> they remove the ovveride redirect flag
<uvos> and then hack around the conseqences with the grab
<uvos> the tlock thing is just a side effect
<Wizzup> well, I don't think we can live with not being able to lock the phone if a map app is fullscreen
<uvos> anyhow tklock needs to hold a grab
<Wizzup> (or a browser, or anything, really)
<uvos> tklock in freemantle is fundamentaly broken
<uvos> as it allows any app to keep focus
<uvos> Wizzup: there is no way to enforce that
<uvos> Wizzup: we can change sdl1.2 to work with ewmh
<uvos> Wizzup: but any old client can just do the same thing
<uvos> Wizzup: tklock must recognize this is happening and disable itself
<uvos> its the only way
<uvos> btw the phone still "locks"
<uvos> as mce disabeles the input
<uvos> just visual tklock cant work
<Wizzup> I guess it's probably not easy to make libsdl do ewmh
<Wizzup> uvos: for me it's more about all libsdl1.2 things playing nice than 'it is possible for an app to break the lock screen'
<Entitlement> uvos - [ 78871 – keyboard/mouse grabs prevent screensave from starting ]
<uvos> Wizzup - takes funding for secuirty research but cares more about his old libsdl1 games than massive security holes in his lock screen.
<uvos> :P
<Wizzup> ah so sdl2 minimises itself it seems
<Wizzup> uvos: I think trying to fix fundamental problems in X by not locking the screen not a particular clean solution either
<Wizzup> clearly if people run misbehaving apps we can't solve all of it, but trying to make our apps play nice I think makes sense
<uvos> im just poking fun
<uvos> we need to do both
<Wizzup> sdl2 code looks quite different from sdl1.2
<uvos> sdl2 just spawns a window
<Wizzup> so doing whatever they did to fix it is likely non trivial
<uvos> and asks the wm nicely to please make it fullscreen
<uvos> the wm then dose whatever it wants
<uvos> sdl1 just takes over x
<uvos> and shuts the wm out
<Wizzup> right
<Wizzup> well I am not sure what happened, but whatever happened, it either crashed X or something else
<Wizzup> when I tried cloudgps with tklock
<Wizzup> so that's not quite nice
<uvos> maybe just pvr
<Wizzup> uvos: maybe we just try to port our stuff to sdl2 or something
<Wizzup> scummvm is sdl2 at least
R0b0t1 has joined #maemo-leste
<uvos> porting to sdl2 is fairly trivial mostly
<Entitlement> uvos - [ MigrationGuide - SDL Wiki ]
<Wizzup> yeah
tkok has joined #maemo-leste
diejuse1 has quit [Quit: Leaving.]
diejuse1 has joined #maemo-leste
xmn has joined #maemo-leste
<Wizzup> nvm doesn't look like scummvm is quite ready for libsdl2, at least the maemo backend
diejuse1 has quit [Quit: Leaving.]
<Entitlement> inky - [ node-keysym/keysyms.txt at master · substack/node-keysym · GitHub ]
<inky> we have here: keysyms, unicode value, then some status field, and then after the comment we have "the name of the X11 keysym macro without the leading XK_"
<inky> your code currently gets the unicode symbol and returns XK_something.
<Entitlement> inky - [ hildon-input-method/hildon-im-xcode.c at 260dc0cfbf91dd78ebcf48deca62ad407f33053... ]
<inky> the first problem i see here is that the switch case checks one byte, while unicode characters are multibyte.
<inky> can we use second and last columns from the file? i. e. U0531 and I can turn Armenian_AYB to XK_Armenian_AYB?
<inky> or in other words should the header be like this or that, see the following:
<inky> #define U0531 XK_Armenian_AYB
<inky> or
<inky> #define Ա XK_Armenian_AYB
<inky> i think i can generate both.
<inky> may be you don't need to call g_unichar_to_utf8() but we can use gunichar? hm.
<inky> uvos, my understanding is that in function KeySym hildon_im_utf_to_keysym(gunichar utf_char)
<inky> we got the gunichar type which is the number from the second column of this https://github.com/substack/node-keysym/blob/master/data/keysyms.txt file.
<Entitlement> inky - [ node-keysym/keysyms.txt at master · substack/node-keysym · GitHub ]
<inky> but i don't know how to confirm that.
<inky> if it is the case then no need to convert that to UTF-8. my first example of header file will suffice.
<uvos> inky: we would use gunichar
<uvos> inky: i would reccomend maybe something like this:
<uvos> const gunichar utfcode[] = {0xUnicodeCodepointAsHex, 0xUnicodeCodepointAsHex, ...} and const XKeySymb xsymcode[] = {0xhexOfXsymb, 0xhexOfXsymb, ...}
<uvos> and have them sorted by utfcodes
<uvos> so i can then implement a binary search
<uvos> for the index i
<uvos> and then pass xsymcode[i] to Xorg
<inky> oh!
<inky> okay!
<inky> can you give me very short example
<inky> like
<uvos> sure
<inky> you can use Armenian_AYB from here
<Entitlement> inky - [ node-keysym/keysyms.txt at master · substack/node-keysym · GitHub ]
ikmaak has quit [Ping timeout: 260 seconds]
<uvos> note i dident sort them
<uvos> i fixed it
<inky> let me see (:
<inky> oh so you need info from first and second columns. i thought you need second and last. (:
<inky> okay, i'll do that! may be very soon. (:
<uvos> inky: ok :)
<uvos> inky: bonus points if you include keysymdef.h
<uvos> and use the second and last and do this:
<uvos> (i updated the testheader.h file)
<uvos> this way the #defines in keysymdef.h set the hex values for the keysymbs
<uvos> is also more readable
ikmaak has joined #maemo-leste
<uvos> the armenian alphabet is honestly pretty
<uvos> never seen it before
<inky> heh. (:
<inky> i can generate the header as in your last example by only using the file with four columns from node library.
<inky> because it contains what you want in the second array.
<inky> i just need to add XK_ to those lines.
<uvos> inky: looks like
<uvos> thats great
<uvos> so then #include <X11/keysymdef.h> is sufficent to get the hex values
pagurus has joined #maemo-leste
diejuse1 has joined #maemo-leste
<diejuse1> One question. Is it possible to install applications or games from other repositories through Hildon Application Manager? I remember that many games appeared on the Nokia N900.
<buZz> diejuse1: many of the older maemo applications and games need some work done to work in leste
<buZz> its not always a lot of work though
<buZz> but you cant add just add a repo from another maemo version and install them
<buZz> diejuse1: BUT, you can install stuff from the ~60000 programs in devuan ;)
<diejuse1> buzz: Ok, it needs more work to get it
<buZz> maemo leste much more than previous maemos is 'real' devuan underneath
<diejuse1> you mean using "apt-get"
<buZz> yeah
<diejuse1> It would be nice to install devuan apps with GUI
<Wizzup> diejuse1: many games on fremantle are open source, it's usually not too hard to port them
<Wizzup> which one(s) were you thinking of
<buZz> diejuse1: a lot of devuan apps with gui just work directly ;)
<buZz> suprisingly many, anyway
<diejuse1> Wizzup: free civilization
<buZz> freeciv? lets see
<diejuse1> yes
<Wizzup> I think freeciv had patches for not having a right mouse button
<Wizzup> buZz: ^
<buZz> i bet thats in debian
<Wizzup> like I said, patches for right mouse button :)
<buZz> do i want 'gtk' or 'gtk3'
<diejuse1> I understand
<Wizzup> buZz: do you think debian ships those maemo patches? :p
<buZz> lol no, just wanted to see it run
<buZz> interesting bug , onscreen keyboard button for ':' actually types ';'
<buZz> and button for ';' types nothing
<Entitlement> buZz - [ png (960 x 540) ]
<buZz> menu a bit big :P lol
<buZz> anyone else seeing that vkb bug?
<buZz> or did i just mess something up on my end
<diejuse1> buZz: yes, I knew it worked, I installed it too. My question was could I install it through Hildon Application Manager.
<buZz> :)
<buZz> atm not
<diejuse1> I knew it worked, I installed it too. My question was could I install it through Hildon Application Manager.
<diejuse1> I have also added webapp icons.
<diejuse1> like Google Docs
<diejuse1> I think Maemo Leste has a lot of potential to use webapps.
<Wizzup> yeah, eventually
<diejuse1> I have downloaded some 128x128 icons. I have added them to /usr/share/icons/hicolor/128x128. After I create a .dektop file with "exec=chromium --no-sandbox --new-window --app=https://docs.google.com"
<Entitlement> diejuse1 - [ Sign in - Google Accounts ]
<diejuse1> Using these flags it opens as if it were a Hildon application.
<Wizzup> :)
<Wizzup> yep
<uvos> buZz: yeah the x11 backend to him has this bug
<buZz> ah ok
<uvos> buZz: inky is currently tasked with solveing this
<buZz> so, no need to report it i guess
<uvos> no
<uvos> x11 backend is currently a alpha preview
<inky> see if that will work.
<uvos> inky some of those dont exist in keysymdef :\
<uvos> like XK_Armenian_eternity
<uvos> we have to cross referance keysymdef.h and remove those that are not in there
<uvos> inky: also sorting is not correct
<uvos> there is 0xfd01 and some time later 0x06ad
<uvos> but thats not a big deal for now
<uvos> i could use a linear search
<inky> hmmm. may it be more modern keysymdef.h has those?
<inky> let me try to remove those that aren.t present in keysymdef.h
<uvos> inky: no they are missing in xorg 1.20
<uvos> so thats the most modern version
<uvos> unless you mean git
<inky> okay let me see how many lines aren't in xorg.
<inky> i found only one that is not in keysymdef.h
<inky> it is XK_dead_horn
<inky> and indeed
<inky> there was a comment
<inky> in the source file
<inky> minute
<uvos> XK_dead_horn is in my keysymdef.h
<uvos> but XK_Armenian_eternity is not
<uvos> what keysymdef.h are you using
<uvos> ?
<inky> the one you gave me link to today. (:
<inky> wait.
<inky> i think this
<uvos> i cant find XK_Armenian_eternity in there
<inky> yes that's it.
<inky> let me see
<inky> somehow my script found it.
<uvos> grep XK_Armenian_eternity /usr/include/X11/keysymdef.h also nothing
<uvos> (on droid4)
<inky> you are right, wait.
<inky> (:
<inky> found, the number of missing lines is
<inky> 27
<Entitlement> inky - [ dpaste: missing.txt ]
<uvos> inky: ok
<uvos> inky: btw can you also remove the keysyms that have d in the third collum in https://github.com/substack/node-keysym/blob/master/data/keysyms.txt?
<Entitlement> uvos - [ node-keysym/keysyms.txt at master · substack/node-keysym · GitHub ]
<inky> now fixed.
<inky> oh wait
<inky> let me add that 'd' check as well.
<inky> out.h updated
<inky> script that generated the header is here: https://github.com/norayr/gen-header-for-hildon-input-method
<Entitlement> inky - [ GitHub - norayr/gen-header-for-hildon-input-method ]
<inky> checked http://norayr.am/tmp/out.h doesn't contain lines marked with 'd' symbol.
<inky> wait now it has other problem.
<uvos> hmm?
<uvos> missaligned?
<inky> no everything is right. nevermind. i overthinked. (:
<inky> please download the file again http://norayr.am/tmp/out.h
<uvos> what changed?
<inky> now i am sure everything is right.
<inky> i was grepping for
<inky> XK_<symbol> in keysyms.h
<inky> to check if it is there
<inky> but now i searched for "define XK_<symbol> "
<inky> with whitespace in the end of string.
<inky> because some XK_something could countain other XK_something
<inky> and actually the only difference is availability of XK_uo which was found in other string.
<inky> now %100 right.
<inky> there is XK_uo and there is XK_uogonek in keysymdef.h
<inky> so it was adding XK_uo but it didn't have to.
<inky> that was the problem.
<inky> now fixed.
<uvos> setxkbmap <what> is appropriate for armenian?
<inky> am
<inky> am is for typewriter
<inky> there is am(phonetic) variant for phonetic.
<inky> and some other variants.
sunshavi has quit [Read error: Connection reset by peer]
<inky> ah i just understood why are you asking.
<inky> am is enough. (:
<uvos> it works
<uvos> i can type Armenian
<kek> IMbackK opened a pull request: https://github.com/maemo-leste/hildon-input-method/pull/6 (allow x11 backend to type more unicode chars)
diejuse1 has quit [Ping timeout: 260 seconds]
<uvos> Wizzup: ^^^ kindly merge into devel
<uvos> inky: can you uplodad you script somewhere
<uvos> so we can regenerate the fille if need be
<uvos> ?
<uvos> i can also write umlauts
sunshavi has joined #maemo-leste
<inky> yes uploaded!
<Entitlement> inky - [ GitHub - norayr/gen-header-for-hildon-input-method ]
<inky> yay!
<inky> you can type!
<uvos> no i just have to implement the logic to change xkeymaps whever the vkb is opened in x11 mode
<uvos> so you can type any char while peserving the hwkb functionality
<uvos> but not today
<inky> that's okay.
<inky> take your time! (:
<inky> i am happy that some day i will do apt-get upgrade and get this.
<inky> and my friend may stick with maemo then.
<inky> on a pinephone.
<Wizzup> uvos: will merge after dinner, great!
<kek> IMbackK synchronize a pull request: https://github.com/maemo-leste/hildon-input-method/pull/6 (allow x11 backend to type more unicode chars)
<uvos> the way the shift key works is great :D
<uvos> so A and a are different keysims
<uvos> but they share a key code
<uvos> so to give a window A you must set the modifier mask to shift when you send the code
<uvos> but how do you know what sym is uppercase?
<uvos> well you ask x to translate the sym to a code
<uvos> and then back to a sym
<uvos> if the sym you end up with is no the same one that went in you need shift
<uvos> xinput is lovely
jonsger has joined #maemo-leste
diejuse1 has joined #maemo-leste
ikmaak has quit [Read error: Connection reset by peer]
ikmaak has joined #maemo-leste
mardy has quit [Quit: Lost terminal]
<Wizzup> uvos: the header file, is it something we can generate in the build system?
<Wizzup> uvos: hildon-im-xcode-keysyms.h I mean
<uvos> Wizzup: yes
<uvos> Wizzup: but im unsure how usefull that would be
<Wizzup> I don't know, if they more get added in the future, we'd get them by rebuilding
<uvos> Wizzup: as it was just generated from the node.js file
<Wizzup> node.js file?
<uvos> Wizzup: and thats not a authorative source
TheDoctor is now known as BenLand100
<uvos> infact it was wrong in places
<uvos> Wizzup: we got the input data from this https://github.com/substack/node-keysym
<Entitlement> uvos - [ GitHub - substack/node-keysym: Convert among X11 keysyms, unicodes, and string n... ]
<Wizzup> ah, so it wasn't autogenerated?
<uvos> yes you are reading that right
<uvos> the header was but from data from that programm
<Wizzup> well I meant, can we generate that data?
<uvos> no
<uvos> we could include the file from node-keysym in our repo
<uvos> and then generate the c header from that
<uvos> i dont think this is usefull
jonsger has quit [Ping timeout: 240 seconds]
<kek> IMbackK opened an issue: https://github.com/maemo-leste/bugtracker/issues/534 (Import salutem into core)
<Wizzup> uvos: ok
belcher_ has joined #maemo-leste
belcher has quit [Ping timeout: 265 seconds]
belcher_ is now known as belcher
Oksana has quit [Ping timeout: 252 seconds]
uvos has quit [Ping timeout: 240 seconds]
Oksana has joined #maemo-leste
diejuse1 has quit [Quit: Leaving.]