_inky has joined #maemo-leste
Pali has quit [Ping timeout: 245 seconds]
_inky has quit [Ping timeout: 252 seconds]
_inky has joined #maemo-leste
zhxt has joined #maemo-leste
_inky has quit [Ping timeout: 245 seconds]
inky has quit [Ping timeout: 245 seconds]
<mighty17[m]> <MartijnBraam[m]> "the pmos n900 kernel is a bit..." <- We should package openpvrsgx kernel for pmos :D
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
zhxt has quit [Ping timeout: 245 seconds]
^-^hi has joined #maemo-leste
<^-^hi> Ok, so bootlocks only let one type of kernel they have signed to boot
<^-^hi> And Android runs some sort of Linux
<^-^hi> And Linux's kernel could be upgraded on the fly as I heard.
<^-^hi> So... can one boot the Android kernel and then change it to mainline Linux after the boot, thereby salvaging the bootlocked phones?
<sicelo> Yes. That's what kexecboot does on the motorola droids, and lk2nd in the qcoms.
Danct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #maemo-leste
Twig has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> Wizzup: no
<uvos> Wizzup: but i do test it on amd64 arch linux
<freemangordon> Wizzup: yes, please http://46.249.74.23/leste/n900/
zhxt has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
xmn has joined #maemo-leste
xmn has quit [Ping timeout: 252 seconds]
<freemangordon> openpvrsgx doesn;t boot either
<uvos> did you try vanilla?
<freemangordon> pulling linux stable ATM
<dreamer> heh. friend had noticed some TI userspace build activations on 3430 and 4430 trees recently. but was wondering why 3630 wasn't done hehe
<dreamer> the sgx handling, right?
<mighty17[m]> Is the green lines GPU issue?
<mighty17[m]> Or display
<Wizzup> freemangordon: trying now
<Wizzup> freemangordon: did you append the dtb, btw?
<freemangordon> yes
<freemangordon> wait, I have dmesg log
<freemangordon> looking at it ATM
<freemangordon> acx565akm spi0.2: failed to find video source
<freemangordon> any idea?
<freemangordon> tmlind: ^^^
<Wizzup> is this omap2plus_defconfig ?
<freemangordon> no
<freemangordon> lemme try with it
<uvos> why are we on rc2 again
<freemangordon> this is old dmesg
<freemangordon> with vanilla I have the same error
<freemangordon> uvos: https://pastebin.com/Tbbf9RgL
<freemangordon> the same with openpvrsgx tree
<sicelo> Nice! It's always the display :-(
<Wizzup> btw, I tried on serial and uh it doesn't boot for me on several tries which is weird, also no output on serial, let me try once more
<Wizzup> I thought extra_bootargs with console= set to serial would work but maybe that appends the arg
<freemangordon> Wizzup: don't waste time I have dmesg log
<Wizzup> ok
<uvos> just stabbin in the dark here but maybe omapdss dosent probe? boot with initcall_debug=1 nd ignore_loglevel=1
<uvos> maybe
<uvos> or since it boots ssh in and take a look around in sys and proc
<freemangordon> I can;t ssh
<freemangordon> also, I see no dss logs, so maybe you are right
<freemangordon> but, lemme trey with omap2plus_defconfig first
<uvos> ok
<freemangordon> with omap2plus_defconfig it doesn't write anything in /var/log
<freemangordon> I guess it dies before mounting root
<Wizzup> is this plain 5.15
<Wizzup> I can try to build it today
<freemangordon> wait, I think I know what happens
<freemangordon> but yeah, you may try vanilla with omap2plus_defconfig to see why it hangs
<Wizzup> latest rc?
<freemangordon> yes
<freemangordon> rc-4
<freemangordon> iiuc
<Wizzup> sicelo: (and others) btw, if you know of a way to produce a few serials at not an insanely high cost I'd like to know
<Wizzup> freemangordon: ok, but it will be later today, maybe late afternoon or eve
<freemangordon> ok, no hurry
<uvos> some one has to design them
<uvos> i can make some
<Wizzup> uvos: sre designed them
Pali has joined #maemo-leste
<uvos> there are no files and he used a laser cutter wich i could do but its not a great idea
<Wizzup> but we'd need to order the parts and use a cnc
<Wizzup> I also have a laser cutter at the local hackerspace here
<Wizzup> aren't there files?
<uvos> i have various cnc machines
<Wizzup> neat
<sicelo> no there arent. but i'm sure he could share them if we ask
<Wizzup> i'm sure he'll share the files
<freemangordon> I think it would be better to re-desigh to use a simple flex cable (an a terminator) that lives under the battery
<uvos> i dont like the dsign
<uvos> really
<freemangordon> me neither
<uvos> tentioning the flex cable might be hard
<uvos> an easy way to do it
<uvos> would be to use a flex cable with the same pin pattern as the n900
<uvos> and then using conductive adheasive
<freemangordon> adhesive?
<uvos> like is used on lcd display cables to bond to the glass
<uvos> yeah
<freemangordon> this is even worse
<freemangordon> I mean:
<freemangordon> you can;t reuse that device anymore
<uvos> why just have the cable wrap around the battery
<freemangordon> unless I missed the point
<uvos> on the other end of the flex you have a eadge connector
<freemangordon> uvos: wait, you need to have pogo-pins contacting the MOBO
<uvos> freemangordon: no here 1 sec
<uvos> so you have a flat flex
<uvos> and a regular pcb
<uvos> on the regular pcb you have the voltage level conversion and usb uart chip
<uvos> the flat flex is just long enough to wrap arround the battery half way
<freemangordon> ok
<uvos> on the other end you have the n900 pad pattern exposed
<uvos> you bond the n900 end to the mainboard permanently
<uvos> and wrap the flex around the battery
<uvos> so you can still close the door
<uvos> if you want serial you open the door an plug in the regular fr4 pcb
<freemangordon> uvos: everything is fine, besides the 'bond' part
<freemangordon> as soon as you disconnect, you have 4-5 cm wire attached directly to SoC hanging in the air
<uvos> ? to the pcb not the soc
<uvos> and its just a pice that goes around the battery a half turn
<freemangordon> it is PCB, but there are no bufers or sumething
<freemangordon> so basically it is to the SoC
<uvos> i dont think its a big problem emi wise
<uvos> you would only connect the uart pins ofc
<uvos> the rest you bond for stability
<freemangordon> I would say it is, because, as I said, there is no buffersing
<uvos> but dont give them any long tail
<uvos> dont worry fine electrically
<freemangordon> so you attach an antenna to the SoC
<uvos> yeah but just to the uart pins
<freemangordon> doesn;t really matter, as long as there are no buffers or filter caps
<freemangordon> afaik this pin is floating
<uvos> yes it dose its not a big deal you might get some noise on the pins but nothing else
<uvos> yes its floating
<freemangordon> what about finding a connector that fits pcb pins and use the battery to keep it attached to the PCB?
<freemangordon> and use bond to attach flex to the connector
<uvos> well then you need a grid of pogo pins
<freemangordon> ok
<uvos> to get defined force
<uvos> i doubt you can do that in the space availbe
<freemangordon> it is not that small
<uvos> its pretty small
* freemangordon checks
<uvos> pogo pins need travel
<freemangordon> I know
<uvos> and a backing of sufficant stiffness
<freemangordon> pcb is ok
<Wizzup> well the pogo pin design of nokia works well no?
<uvos> sure
<Wizzup> at least for me
<uvos> but that replaces the whole battery
<Wizzup> yup
<Wizzup> but sre's is kinda simple
<freemangordon> anyway, back to kernel
<Wizzup> :)
<uvos> machineing a battery shaped object is no issue
<uvos> the premis here was that fmg wants the adapter to work with stock battery
<uvos> anyhow if someone makes cad files for a battery shaped object and a pcb with pogo pins i can machine or 3d print it
<freemangordon> hmm, maybe I should compile on my laptop (8x i7) not on my desktop (4x i5 from 2010 or something) :)
<sicelo> :-)
<freemangordon> not to say that laptop is with nvme
<Wizzup> uvos: we'll also need to order parts to get the proper voltage
<Wizzup> I have this at home, sre gave me one at fosdem
<uvos> i would just design a pcb that integrates the voltage shifter and
<uvos> uart
<Wizzup> aha
<freemangordon> Wizzup: this level shifter is simple mosfets and resistors
<Wizzup> freemangordon: yeah
<freemangordon> yes, as uvos said
<Wizzup> won't it be too much of a time sink?
<Wizzup> otherwise, sounds like a great idea imho
<Wizzup> idk how long it takes to do those things
<uvos> not very long
<uvos> but i dont have any interest in n900 really
<freemangordon> such a simple pcb, maybe a couple of hours
<Wizzup> ok, so we need cad files with the n900 battery size?
<uvos> you might not even need to do any voltage shiftig
<Wizzup> buZz: do you think you can help?
<uvos> there are bound to be some usb uart chips with 1.8v logic level
<sicelo> you do need voltage shifting. the n900 uart is 2.7v
<Wizzup> uvos: it might be neat to allow connecting random 3.3v uarts to the pcb as well
<uvos> sicelo: omap logic level is 1.8
<uvos> not sure where 2.7 would come from
<sicelo> i know. but, N900 uart is 2.7v. sre's design uses 2.5v, which is reasonably close
<uvos> well its ttl i should have 0.8 as the high threshold so anything in that range will work
<uvos> as long as its below the maximum rating the pin
<uvos> let me check the datasheet
<sicelo> uvos: maybe this will make you understand, http://wiki.maemo.org/N900_Hardware_Hacking#Debug_ports
<uvos> so omap3 datasheet says that uart is max 2.1V input with ll high thresh of 1.17V low thesh of 0.63V and output of 1.8V
<uvos> if its doing something else there must be a chip between the uart and the debug port
<sicelo> of course, there is
<uvos> well fmg just said there isent
<freemangordon> well, we don;t know what is there
<uvos> well not omap directly
<uvos> so i see the issue of putting a 3cm lead on there even less now
<freemangordon> its ugly
<uvos> okaaay
<uvos> wel its not my problem
<freemangordon> yeah
<Wizzup> unrelated but I do care about the n900 if only to show that it's possible to make a modern linux smartphone os that mostly just works fine, of course, don't expect browsers to work well
<Wizzup> but I think it's nice to support it
inky has joined #maemo-leste
_inky has joined #maemo-leste
<freemangordon> 5.14.10 boots
<freemangordon> so it is a regression in 5.15 it seems
<uvos> should not be to hard to bisct from there
<freemangordon> yeah
<uvos> we really need some kind of automatic testing
<uvos> that at least checks if the devices boot & load all requesit modules
<uvos> n900 not booting has been a theme..
<freemangordon> going to check if 5.14.0 boots and then will bisect
_inky has quit [Ping timeout: 265 seconds]
inky_ has joined #maemo-leste
<sicelo> nice. that's great progress :-)
inky has quit [Ping timeout: 252 seconds]
<freemangordon> yep, it does
<sicelo> omap2plus? or your own config?
_inky has joined #maemo-leste
uvos has quit [Ping timeout: 252 seconds]
<freemangordon> omap2plus
<freemangordon> WTF? now 5.15-rc4 boots :(
<freemangordon> the difference is that I build it on my laptop
<sicelo> :-)
<sicelo> hehe, i also experienced that a lot - the same kernel would not boot first time, but boot second or third time. i wonder if something doesn't get reset properly somewhere, but my knowledge in this area is lacking.
<freemangordon> no, kernel build on leste does not boot
<freemangordon> I tried maybe 10 different kernels
<freemangordon> the ones build on ubuntu 18.04 boot
<sicelo> mmm. gcc version issues?
<freemangordon> 8.3 vs 8.4, should not make a difference
<freemangordon> well, tmlind's kernel does not boot still
<Wizzup> freemangordon: did you figure out what was up?
<freemangordon> no
<Wizzup> ok
<freemangordon> vanilla boots
<freemangordon> but not tmlind's
<freemangordon> now I am trying to find tag on his tree that boots to bisect
<Wizzup> ok
<Wizzup> and tmlinds is both pvr and other patches?
<freemangordon> droid4-pending-pvr-omapdrm-v5.15
<freemangordon> whatever it is
<Wizzup> ok
<freemangordon> Wizzup: if you have time, please compile and try to get boot log
<freemangordon> bisecting this may turn to be impossible
Twig has quit [Ping timeout: 245 seconds]
Twig has joined #maemo-leste
_uvos_ has joined #maemo-leste
<_uvos_> did you merge in rc4?
<_uvos_> please take rc4 and merge in the pending-pvr branch
<freemangordon> why shall I do that?
<freemangordon> vanilla rc2 boots fine
<_uvos_> ok
<_uvos_> i thought it was rc4
<freemangordon> rc4 too
Twig has quit [Ping timeout: 245 seconds]
Twig has joined #maemo-leste
_uvos_ has quit [Ping timeout: 245 seconds]
_inky has quit [Ping timeout: 245 seconds]
Twig has quit [Ping timeout: 252 seconds]
_uvos_ has joined #maemo-leste
Twig has joined #maemo-leste
inky_ has quit [Read error: Connection reset by peer]
_uvos_ has quit [Ping timeout: 265 seconds]
_inky has joined #maemo-leste
<Wizzup> freemangordon: ok, pls tell me what config and git repo+brachh
<freemangordon> omap2plus_defconfig
<freemangordon> droid4-pending-pvr-omapdrm-v5.15
<freemangordon> Wizzup: ^^^
inky_ has joined #maemo-leste
_inky has quit [Ping timeout: 252 seconds]
<Wizzup> ok
<Wizzup> will do in 1-2 hrs
Twig has quit [Ping timeout: 265 seconds]
xmn has joined #maemo-leste
<freemangordon> why the hell the whole kernel gets rebuild every time I do make? without changing anything?
<Wizzup> freemangordon: shouldn't
<freemangordon> hmm, yeah, false alarm it seems
<Wizzup> just got home
<freemangordon> good
<freemangordon> I have 3 steps to finish the bisect
<Wizzup> ok
<Wizzup> cloning now
<freemangordon> hmm, I guess it is some stupid setting on config, each bisect step leads to a full rebuild
<freemangordon> n ever happened before
<freemangordon> maybe .ko symbols or something
<freemangordon> CONFIG_MODVERSIONS that is
<Wizzup> freemangordon: how do you make the uImage ?
<freemangordon> cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > zImage
<freemangordon> mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -d zImage uImage
inky_ has quit [Ping timeout: 245 seconds]
inky_ has joined #maemo-leste
_inky has joined #maemo-leste
<Wizzup> freemangordon: it's booting for me
<freemangordon> cool
<freemangordon> well, no idea then
<Wizzup> well it doesn't seem to boot all the way to leste
<Wizzup> the screen stays on but black
<freemangordon> the same here
<freemangordon> actually it is stuck
<freemangordon> eventually it will power-down
<Wizzup> [ 15.690734] omapdss_dss 48050000.dss: supply vdda_video not found, using dummy regulator
<Wizzup> [ 15.722290] st-accel-i2c 3-001d: supply vddio not found, using dummy regulator
<freemangordon> shouldn't be an issue
<Wizzup> it's recurring
<freemangordon> ah
<mighty17[m]> The supply not found happens with me aswell, not an issue
<Wizzup> [ 20.243591] rx51-audio n900-audio: snd_soc_register_card failed (-517)
<freemangordon> do you have rootfs mounted?
<Wizzup> yeh
<freemangordon> here is does not mount
<Wizzup> [ 17.445861] lp5523x: probe of 2-0032 failed with error -22
<freemangordon> at least judging by the missing dmesg log in /var/log
<freemangordon> hmm 223790cf892de9cee6a97fdf95c267ad36507951 is the first bad commit
<freemangordon> does not make sense
<freemangordon> drm: pvrsgx: 1.17.4948957 remove never implemented MODULE_SUPPORTED_DEVICE like commit 6417f03132a69
<freemangordon> ok, lemme try again
<Wizzup> just stops there for me
<Wizzup> it doesn't reset for me either
<freemangordon> could you remove dsme from /etc/init.d to see if it will boot to the shell?
<mighty17[m]> `mmc1: switch to bus width 8 failed`
<freemangordon> that's normal
<Wizzup> maybe some depmod is necessary
<Wizzup> unlikely but maybe
<freemangordon> the others boot without depmod
<freemangordon> Wizzup: does it boot to shell with dsme removed?
<freemangordon> or rather - are you able to see any output on the display?
mp107 has quit [Quit: The Lounge - https://thelounge.chat]
mp107 has joined #maemo-leste
mp107 has quit [Client Quit]
mp107 has joined #maemo-leste
<freemangordon> hmm, it boots on b98125a4f1287bc29df93c43abe49cc661030ff4
n9001 has quit [Ping timeout: 252 seconds]
<Wizzup> freemangordon: with display?
<freemangordon> yes
<freemangordon> I mean - I have no other means to distinguish between boot/does not boot but if it displays anything
<freemangordon> on 4a75f05f070785db5ffcbe21bd45b1482ef99e37 I have display too
<freemangordon> not trying the next one
<freemangordon> 614eb7536d3adad342b04fd1666bb3880e660dab that is
<freemangordon> *now trying
<freemangordon> Wizzup: so, what happens on youre device if you remove dsme?
<freemangordon> do you get console?
<Wizzup> can try momentarily
<Wizzup> I don't think so, I think it blocks on udev events to settle or something
<Wizzup> but will try
<freemangordon> ok
xmn has quit [Ping timeout: 245 seconds]
xmn has joined #maemo-leste
<Wizzup> freemangordon: so it's stuck here:
<Wizzup> [ 12.403442] udevd[480]: starting eudev-3.2.9
<Wizzup> . ok
<Wizzup> [....] Synthesizing the initial hotplug events (devices)...
<Wizzup> [ ok ] Synthesizing the initial hotplug events (subsystems)...done.
<Wizzup> (with dsme renamed)
<Wizzup> so no
<freemangordon> same here
<freemangordon> so, actually it does not boot for you :)
<freemangordon> I mean "same" like :no console"
<freemangordon> anyway, I am doing a kind of a manual bisect
<Wizzup> right
<Wizzup> alpine doesn't have eudev probably? not sure what tmlind usually tests with
<freemangordon> no idea
<freemangordon> why the hell on every "git checkout" the whole kernel gets rebuild?!?
<Wizzup> probably a lot of files change mod time
<freemangordon> single file only
<freemangordon> just disabled module symbols versioning, lets see if it will help
<freemangordon> didn;t help
<freemangordon> wtf is going on? it is like I am compiling the kernel for a first time :(
<freemangordon> 33bc438d6d8883d77e37b369fe5144ee9b01fad8 breaks it
<freemangordon> hmm, I think I know why it breaks it, lemme try
<Wizzup> :)
<Wizzup> freemangordon: ^^
<freemangordon> :)
<freemangordon> yeah
n9001 has joined #maemo-leste
<freemangordon> hmm, no, it's something different, I need tmlind
<Wizzup> I guess init=/bin/sh does work?
<Wizzup> must, since it starts openrc
<freemangordon> I'll just revert that commit, to see if pvr works on n900
<freemangordon> because that was the point of the whole exercise
<Wizzup> reverting 33bc438d6d8883d77e37b369fe5144ee9b01fad8 solves your hangs?
<freemangordon> yes
<Wizzup> let me try
<freemangordon> well, on 33bc438d6d8883d77e37b369fe5144ee9b01fad8 it hangs while on d8d18c28963fd9b9ed4425d79c4d5d5d3b496771 it does not
<freemangordon> now building with 33bc reverted to see
<Wizzup> yeah looks like that makes it boot for me too
<Wizzup> waiting to get agetty
<Wizzup> [....] Synthesizing the initial hotplug events (devices)...
<Wizzup> done.
<Wizzup> yeah now it gets past that
<Wizzup> so I can confirm reverting that commit makes it boot
<freemangordon> how you were able to compile so fast?
<Wizzup> model name: AMD Ryzen 7 PRO 4750U with Radeon Graphics
<freemangordon> doesn;t it recompile the whole kernel when you revert?
<Wizzup> 16 threads
<Wizzup> the revert didn't recompile the whole kernel, no
<freemangordon> it does here
<Wizzup> maybe it's a .config option that is enabled?
<freemangordon> something's wrong here it seems
<freemangordon> omap2plus_defconfig
<freemangordon> I'll clone tmlind's tree only
<freemangordon> and try again
<Wizzup> yeah that's what I did
<Wizzup> still, surprising that that would cause udev events to hang
<Wizzup> maybe it causes some operation that doesn't finish on n900 and then omapdrm never probes fully?
<freemangordon> could be
<Wizzup> looks like it
<Wizzup> on this kernel:
<Wizzup> [ 21.217407] omapdrm omapdrm.0: [drm] fb0: omapdrm frame buffer device
<Wizzup> [ 21.343597] [drm] Initialized omapdrm 1.0.0 20110917 for omapdrm.0 on minor 0
<Wizzup> right above that: [ 20.081420] omapdrm omapdrm.0: DMM not available, disable DMM support
<Wizzup> and then without the commit reverted, it never gets past this:
<Wizzup> [ 19.809112] omapdrm omapdrm.0: DMM not available, disable DMM support
<freemangordon> mhm
<freemangordon> hmm, cannot start wpa_supplicant
<freemangordon> Wizzup: any hint how to start usb networking?
<Wizzup> yeah
<Wizzup> /usr/sbin/hildon-usb-gadget-network
<Wizzup> but if you have the same kernel as me then the usb gadget does not work
<freemangordon> maybe I should modprobe something?
Twig has joined #maemo-leste
<Wizzup> I see no wlan0 btw
<freemangordon> me too
<freemangordon> lemme check if it is enabled
<Wizzup> kind of expect it to be
<freemangordon> btw, did you send your patch upstream?
<Wizzup> not yet
<Wizzup> I think it just needs modprobe
<Wizzup> modprobe wl1251
<Wizzup> modprobe wl1251_spi
<freemangordon> lemme check
<Wizzup> oh yeah without that patch icd2 fails heh
<Wizzup> Jan 1 02:16:03 (none) icd2 0.98[2702]: libicd-network-wpasupplicant: close_wpa_control: 0x51bba0
<Wizzup> Jan 1 02:16:03 (none) icd2 0.98[2702]: libicd-network-wpasupplicant: try_open_wpa_control: 0x5422c0
<Wizzup> Jan 1 02:16:03 (none) wpa_supplicant[2711]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-22
<Wizzup> not yet
<freemangordon> yse wext
<freemangordon> *use
<Wizzup> right, that will work, but not what we use on n900 these days
<freemangordon> yeah, but I need only shell anyways
<Wizzup> yeah
<Wizzup> I will let you mess with this now, lmk if you need help
<Wizzup> I'm quite motivated to see if we can move all our pvr stuff to 1.17 somehow..
<freemangordon> I am in through wifi
<Wizzup> ok, then I will get back to droid3 kexecboot
<Wizzup> that's the last thing remaining for me to start writing the news post :D
<freemangordon> [ 808.276550] PVR_K: UM DDK-(4948957) and KM DDK-(4948957) match. [ OK ]
<Wizzup> that's the init?
_inky has quit [Read error: Connection reset by peer]
inky_ has quit [Read error: Connection reset by peer]
<freemangordon> mhm
<freemangordon> and kmscube made it hang :(
<freemangordon> the same regression as with 5.10
<Wizzup> shit
<freemangordon> yeah
inky_ has joined #maemo-leste
<freemangordon> ok, tomorrow I will try to bisect
Twig has quit [Remote host closed the connection]
<Wizzup> rough
<Wizzup> I didn't send the wifi patch in part because I'd have to rebase on latest kernel
<Wizzup> and test it as well
<Wizzup> I might just try to use just modesetting
<freemangordon> hmm, why wl1251 is not probed?
<Wizzup> maybe that's a depmod thing
<freemangordon> ah, right
<Wizzup> will verify now
<Wizzup> (ran depmod -a, rebooting)
<Wizzup> X doesn't start in modesetting without powervr though for me, so need to figure out what's up there
<Wizzup> even unaccelerated X is still helpful in testing wifi patch and such
<freemangordon> mhm
<Wizzup> hm, didn't help (depmod -a)
<freemangordon> :(
<Wizzup> things really never work with computers :D
<freemangordon> yeah
<Wizzup> removing /dev/dri/card1 and /dev/dri/render129 makes X start at least
<freemangordon> bisecting will be a nightmare, there are several things broken in 5.10 IIRC
<freemangordon> like mmc renaming and panel reset
<freemangordon> what I am missing?
<Wizzup> when exactly did it break?
<Wizzup> not exact commit, but version
<freemangordon> I am not really sure
<Wizzup> did 5.9 work?
<freemangordon> ah, in 5.10
<freemangordon> yes, 5.9 did work
<Wizzup> hm
<Wizzup> there must be a sensible way to debug it
<freemangordon> yeah, jtag :)
<Wizzup> did anyone ever manage to do that? ;)
<freemangordon> sure, in TI/Nokia ;)
<Wizzup> I wonder if the device I have here can do it
<Wizzup> parazyd: the latest vm images will lock the screen upon timeout, and then *all* input devices are disabled
<Wizzup> and then it's not possible to unlock unless you send the 'power' key to the vm
<Wizzup> I don't have this problem on my dev vm, so IDK what's different
<Wizzup> but it's likely something inside of the images, rather than leste-config related?
ikmaak2 has joined #maemo-leste
ikmaak has quit [Quit: No Ping reply in 180 seconds.]
_inky has joined #maemo-leste
<Wizzup> parazyd: ah my vm has 'lock screen automatically' disabled
<Wizzup> but the fresh image does not
^-^hi has quit [Ping timeout: 245 seconds]
^-^hi has joined #maemo-leste
belcher has quit [Ping timeout: 252 seconds]
belcher has joined #maemo-leste