xes has quit [Ping timeout: 268 seconds]
xes has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
xes has quit [Remote host closed the connection]
xes has joined #maemo-leste
xes has quit [Remote host closed the connection]
uvos__ has quit [Ping timeout: 252 seconds]
uvos__ has joined #maemo-leste
xes has joined #maemo-leste
xes has quit [Read error: Connection reset by peer]
xes has joined #maemo-leste
xes has quit [Read error: Connection reset by peer]
xes has joined #maemo-leste
xes has quit [Remote host closed the connection]
xes has joined #maemo-leste
joerg has quit [Ping timeout: 246 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
macros_ has joined #maemo-leste
uvos__ has quit [Ping timeout: 248 seconds]
uvos__ has joined #maemo-leste
xes has quit [Remote host closed the connection]
<freemangordon> buZz: 144p works fine in chromium, fullscreen as well
<freemangordon> 240p too, but might not fluid at times
mardy has joined #maemo-leste
xes has joined #maemo-leste
rafael2k has joined #maemo-leste
<tmlind> freemangordon: if you have a chance, maybe comment on the list regarding sony,acx565akm for the old omapfb? imo, we should do minimal fix, then drop the old omapfb stuff unless there's a reason to keep it still?
<tmlind> and panel-dsi-cm too can go looks lie
<tmlind> like
<rafael2k> this 6.0 kernel might be worth trying in the PP, especially in PP 1.1 (Braveheart) as it clearly states it is supported
<rafael2k> pre-compiled kernels are available here (still in the 5.19, but mostly same patchset: https://xff.cz/kernels/5.19/ )
<rafael2k> we could change to this megous branch in case it works better...
ceene has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
alex1216 has joined #maemo-leste
akossh has joined #maemo-leste
<buZz> freemangordon: i wonder why it doesnt for me then :(
pere has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
alex1216 has joined #maemo-leste
uvos__ has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 246 seconds]
uvos__ has joined #maemo-leste
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
<buZz> whats the CI channel again?
<Wizzup> #leste-ci
<Wizzup> ##leste-ci
<freemangordon> buZz: what i sthe UA you're using?
<buZz> ehw, lets see
<freemangordon> make sure it is iphone6 or windows phone
<freemangordon> so mobyle YT to open
<freemangordon> *mobile
<buZz> its Mozilla/5.0 (iPad; CPU OS 11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Tablet/15E148 Safari/604.1
<buZz> whats yours?
<freemangordon> what browser is that?
<freemangordon> is that chromium?
<buZz> yes
<buZz> just apt install chromium
<freemangordon> what extension do you use to change the UA?
<freemangordon> user-agent switcher for chrome is what I use
<buZz> i think me too? lets see
<freemangordon> ugh. battery went flat :(
<buZz> this one
uvos__ has quit [Ping timeout: 246 seconds]
uvos__ has joined #maemo-leste
<freemangordon> buZz: also, make sure it plays @ 144p
<freemangordon> so, site must be m.youtube.com
<buZz> yeah i did
<buZz> i'll try your plugin first
<freemangordon> d4 just cannot handle desktop site
<buZz> its grabbing the m.youtube already
<freemangordon> hmm, it does not play here as well
<freemangordon> wtf?
<freemangordon> maybe they have changed something
<freemangordon> buZz: oh, I know what happens
<buZz> oh?
<freemangordon> sometimes I have to reboot the device, otherwise, for some reason YT playback is choppy
<freemangordon> for some reason, sometimes after reboot GPU is not in a mood
<buZz> hmm, weird
<freemangordon> yep, rebooting atm, lets see
<buZz> wonder if we could detect that, beside yt playback
<freemangordon> no idea
<freemangordon> maybe some difference in regs
<buZz> i wonder if its better on coldboot vs reboot
<buZz> or the inverse
<freemangordon> no pattern I am aware of
<freemangordon> but, it happens occasionally
<buZz> sometimes reboot seems to hang for me too, after motorola logo, taking a long time before kexecboot shows
<buZz> maybe 10x longer than 'normal'
<freemangordon> yep, after reboot it plays 240p with no issues
<buZz> gee! , just a warm reboot?
<freemangordon> power down
<buZz> so , a cold boot?
<freemangordon> yes
<freemangordon> but I am not sure it matters
<freemangordon> but again, no known pattern
<buZz> weird :)
<freemangordon> the only difference I am aware of is that it entered charge mode when it was choppy
<freemangordon> but I doubt this is the reason
<freemangordon> also, the whole display was full with renderning artefacts
<buZz> the ants?
<freemangordon> legions of them, everywhere :D
<buZz> was your battery really low when driver initialized?
<freemangordon> yes
<buZz> hmmmmm :)
<freemangordon> I think it is related
<buZz> yeah my suspicion too
<buZz> +spelling
<freemangordon> git it :)
<buZz> just like how the modem seems to behave weird at <20%
<freemangordon> *got
<freemangordon> and my battery is really old
<buZz> same here\
<freemangordon> most-probably related
<freemangordon> will see when replacement battery arrives how it will behave
<buZz> which battery did you order?
<freemangordon> the one uvos is using
<freemangordon> don;t remember the exact model
<buZz> ah nice, i want one too
<buZz> does it have the flex lips like d4 uses already?
<freemangordon> no, I will have to modify
<buZz> or would it require that flexpcb design he shared
<freemangordon> will see if I will manage to :)
<buZz> i was looking that we could maybe expand that flexpcb to have the connections for a thermistor too
<buZz> and maybe make it slightly more universal
<freemangordon> I will try to plant the whole circuitry from the old battery
<buZz> just put the thermistor on that flexpcb
<buZz> ah yeah , that works too
<buZz> i'm still hunting for a new produced HV lipo that fits the case
<freemangordon> tmlind: TBH, I don;t feel experienced enough to comment - neither do I fully understand what the issue dmitry is fixing is about, nor the follow-up discussion
* buZz puts pizza slices on the table for all
<Wizzup> our raspi4 images are kinda broken
<Wizzup> the kernel compile fails
<Wizzup> heh
<buZz> :(
<buZz> sad
<Wizzup> somehow it boots
<Wizzup> :D
<Wizzup> but it's llvmpipe and no modules
<buZz> oh :P haha
<buZz> still had a old kernel on it?
<Wizzup> buZz: not sure how yet
<buZz> Temporary failure resolving 'maedevu.maemo.org'
<buZz> ?
<buZz> dont pi's normally have a seperate partition with the kernel?
<norayr> also yewtu.be, i guess this was the domain, is an invidious instance, and it has very leightweight ui, even for a computer
<norayr> i often use it to decrease the load of the machine
<norayr> but maybe it doesnt have 144p
<Wizzup> freemangordon: where did you put iphbd-dkms ?
<Wizzup> freemangordon: the raspi can't find it
<Wizzup> it's not in the droid4 component is it?
<Wizzup> doesn't look like it
<Wizzup> ah nvm, it's complaining about linux headers
<Wizzup> unsurprisingly..
<buZz> norayr: i'd like to record using actual youtube in the background though
<buZz> as google now -charges money- for that luxury
<buZz> (as youtube premium, one of the features is 'background playback')
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #maemo-leste
uvos__ has quit [Ping timeout: 268 seconds]
pere has quit [Ping timeout: 246 seconds]
<Wizzup> apparnetly linux-headers-arm64 does not provide linux-headers? eh
<buZz> might be the issue i saw earlier? where our kernels dont build source packages
<buZz> imho -headers is still source
<Wizzup> no, seems very unrelated :D
<buZz> hehe ok
<tmlind> freemangordon: i replied what i think is going on with the panels, maybe take a look and comment if there's any need for the old omapbf drivers in question
<tmlind> omapfb panel drivers i mean
<buZz> tmlind: do you have any idea if the omap gpu driver could support .icc profiles for color correction?
<buZz> -could
<tmlind> buZz: no idea whatsoever
<buZz> alright :) i'll try soon
uvos__ has joined #maemo-leste
<uvos__> buZz: the hang at the motorola logo
<buZz> -after- the logo
<uvos__> right also after
<buZz> screen is black then
<uvos__> (ie at black)
<buZz> yeah
<uvos__> is some bug in the stock kernel caused by the uart module thats loaded by the intercept
<uvos__> its related to the modem
<buZz> hmmm
<uvos__> if the modem is busy and uses the uart the kernel hangs
<buZz> so maybe that kexecboot kernel needs some 'ignore uarts' flag ?
<uvos__> no
<buZz> oh ok
<uvos__> so the problem is that the kexec module loads a hacky uart module
<uvos__> s/loads/depends
<buZz> what would that need a uart for?
<uvos__> this was done by the linageos people because there is no way to get debug output at all
<buZz> ah
<uvos__> while writeing the kexec module
<uvos__> but its buggy somehow
<buZz> but then still kinda sounds like we dont need uarts there?
<uvos__> if the modem uses its uarts while the hacky uart module is active
<uvos__> stock kernel crashes
<uvos__> i "fixed" this on my device
PureTryOut[m] has quit [Quit: Bridge terminating on SIGTERM]
<uvos__> by adding a 10 sec delay
n00mann[m] has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam[m] has quit [Quit: Bridge terminating on SIGTERM]
humpelstilzchen[ has quit [Quit: Bridge terminating on SIGTERM]
jedertheythem[m] has quit [Quit: Bridge terminating on SIGTERM]
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
tvall has quit [Quit: Bridge terminating on SIGTERM]
<uvos__> this ensures the modem has setteled more
<uvos__> and the crash never happens on my device
<uvos__> but its not really a fix
<uvos__> fixing this problem is hard beacuse its in the module you need to get any output at all
<buZz> cant we just remove that lineageos change then?
<uvos__> no
<uvos__> its required to kexec
<buZz> aw
<uvos__> you could remove all the debug prints in the kexec module
<uvos__> and then not use the hacky uart module
<buZz> yeah that was my suggestion
<uvos__> but then you have no debug output during kexec
<buZz> remove the dependancy
<uvos__> so thats not great either
<buZz> i guess, but when was last time you debugged kexec?
<uvos__> well right now
<uvos__> xD
<buZz> :P
humpelstilzchen[ has joined #maemo-leste
<uvos__> buZz: as for if omapdrm could do color transformations
<uvos__> shure you could do it on a pvr shader no problem
MartijnBraam[m] has joined #maemo-leste
<uvos__> thats how modesetting works
PureTryOut[m] has joined #maemo-leste
mighty17[m] has joined #maemo-leste
jedertheythem[m] has joined #maemo-leste
<buZz> uvos__: no problem, as in no penalty in speed?
n00mann[m] has joined #maemo-leste
<uvos__> well not zero
tvall has joined #maemo-leste
<uvos__> but low
<buZz> sounds good
<norayr> people, i want to get linux-image-omap kernel sources, added deb-src
<norayr> copied our maemo lines in sources.list, but changed deb to deb-src
<norayr> apt-get update, apt-get source linux-image-omap doesn't get me the source.
<norayr> i would like to get the source, change a couple of things in light meter driver source, my friend believes there is a bug there.
<norayr> and metered light differs dramatically from other devices.
<buZz> yeah there's no source package for the kernels i think :(
<buZz> wish we did
pere has joined #maemo-leste
<uvos__> norayr: just grab it off git
<uvos__> since we have quite a few devices that are stuck with gprs/edge in most places now
<uvos__> maybe we should run a compression proxy like https://github.com/barnacs/compy
<buZz> ssh -C works too :P
<uvos__> on https webpages?
<uvos__> not really
<buZz> hehe, no
<buZz> :P
<buZz> but dont almost all webservers do onthefly gzip nowadays?
<uvos__> no all, also the greates benefit of compy is that it reencodes the images
<uvos__> to make them smaller
<uvos__> this is huge saveings
<uvos__> for little loss on a phone sized screen
<Wizzup> buZz: there are source packages for kernels
<buZz> Wizzup: see norayr just now?
<norayr> but how the kernel source package is named for droid4?
<norayr> it said Picking 'omap-linux' as source package instead of 'linux-image-omap'
<norayr> E: Unable to find a source package for omap-linux
<uvos__> norayr: maemo-5.18.y branch
<norayr> 5.18.19 tag
<norayr> will try to not rebuild everything, but only module. not sure how.
<freemangordon> no way, you need the whole kernel
<uvos__> why, you can for sure buid just one module
<Wizzup> git checkout https://github.com/maemo-leste/droid4-linux.git -b 5.18.19 --depth 1
<freemangordon> or, you can get kernel headers and build as out-of-tree module
<freemangordon> uvos__: no, because of the module versioning
<norayr> i want to rmmod the module, and then...
<norayr> thank you, Wizzup!
<freemangordon> well, if he copies debian build scripts etc
<freemangordon> but then again, it is easier to just build the whole kernel, copy to device and start playing
<uvos__> sure
<freemangordon> well, at least for me is easier :)
<norayr> i don't understand, debian build scripts will help me to build the whole kernel, not only the module.
<norayr> ok let's see.
<uvos__> but its hardly impossible to build one module for the installed kernel
<norayr> Wizzup: that's not the branch 5.18.19, i guess, that's tag.
<freemangordon> debian build tree will help you to build the correct kernel symbols version
<uvos__> -b command takes tags too
<uvos__> despite the name
<uvos__> @norayr
<freemangordon> if you know what you are doing
<norayr> i don't (:
<freemangordon> me neither, that's why I am building the whole kernel :)
<norayr> let's see, i'll try.
<uvos__> so regarding the als units
<uvos__> the cange is trival to do
<uvos__> but idk if the mapphones are off because its a bug in the kernel with what units it presents on sysfs
<uvos__> or if the mapphones have a variant of the als chip
<uvos__> thats different
<uvos__> in case 1 you can just change the scale file in sysfs
<uvos__> in the other case you would need to add a dts parameter
<uvos__> to know what it is you would need to have the chip in some other form than just in a mapphone
<uvos__> so i decided not to deal with this
<norayr> i'll show you the fix by my friend, i'll understand it better when i apply it.
<norayr> not sure it'll change the behaviour of als.
<norayr> but let's see.
<buZz> imho, would be easier if we had kernel source packages :P
<norayr> yes. of course.
<norayr> i was sure we have. (:
<norayr> should i also take droid4 config from git?
<norayr> ah, i'll take it from /proc/config.gz
<freemangordon> omap2plus_defconfig, no?
<norayr> i don't know? there are configs for devices on git.
<freemangordon> uvos__: Wizzup: we are using omap2plus_defconfig, right?
<uvos__> freemangordon: yes
<uvos__> but config.gz will work fine too
<uvos__> ofc
BenLand100 has quit [Quit: s/BenLand100//]
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
uvos__ has quit [Ping timeout: 268 seconds]
xes has quit [*.net *.split]
Langoor has quit [*.net *.split]
sicelo has quit [*.net *.split]
Langoor has joined #maemo-leste
xes has joined #maemo-leste
sicelo has joined #maemo-leste
sicelo has quit [Changing host]
sicelo has joined #maemo-leste
joerg is now known as DocScrutinizer
* DocScrutinizer pokes buZz
DocScrutinizer is now known as joerg
<buZz> hiya :)
<buZz> *sigh* ok, i think i found why my .deb keeps having nothing inside
<buZz> the 'make install' on this project does nothing -_-
<buZz> guess i'll just have to add a pile of cp commands somewhere
<Wizzup> buZz: does it not use cmake or autotools?
<Wizzup> maybe look how many of the other debian/rules files look
<buZz> it uses cmake, but somehow it doesnt have any installation files
<Wizzup> what are 'installation files' ?
<buZz> i mean , 'make install' after running cmake doesnt copy any compiled binary to anywhere
<Wizzup> freemangordon: ok, I have a lime2 with 7" ts and 800x480 screen working
<Wizzup> I had to hack a bit on our sunxi image and copy some olimex files, but it's working
<buZz> cool!
<buZz> decent speed?
<Wizzup> gimme a bit
xmn has joined #maemo-leste
<buZz> all the bits
<Wizzup> needed to figure out net.ifnames=0 :)
<rafael2k> net.ifnames=0 ❤
<Wizzup> yes
uvos has joined #maemo-leste
mrkrisprolls has quit [Ping timeout: 260 seconds]
rafael2k has quit [Ping timeout: 246 seconds]
Danct12 has quit [Remote host closed the connection]
ceene has quit [Remote host closed the connection]
<freemangordon> I guess I will have to buy another uSD card to resurrect my allwinner
<Wizzup> which allwinner is this?
* Wizzup just bought a few microsd cards
alex1216 has quit [Quit: WeeChat 2.3]
<buZz> so cheap nowadays :)
<Wizzup> freemangordon: do you remember if we needed any kernel patches for some of the flickering of lima to go away?
Danct12 has joined #maemo-leste
<buZz> freemangordon: just to confirm, indeed, 144p playback was bad, reboot, and it was smooth
<freemangordon> Wizzup: q8 a33 is all I remember
<Wizzup> right the plesio one
<Wizzup> I have a lime2 here showing 4g connectivity :)
<freemangordon> lemme check in android
<Wizzup> fixing gps atm for the demo
<Wizzup> the raspi also works with 3d and touchscreen,wifi etc
<freemangordon> nice :)
<norayr> i also feel that charging does something bad to droid4. i think it is already better than a month ago.
<freemangordon> norayr: there was a pile of fixes/improvements top xorg driver
<norayr> yes, i was seeing something is happening. (:
<freemangordon> Wizzup: Q8H_HD
<freemangordon> I remember I had issues with TS
<freemangordon> had to copy firmware or something
mrkrisprolls has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
<Wizzup> probably dts needs updates too for newer kernels
Twig has joined #maemo-leste
<freemangordon> mhm
<Wizzup> it seems that mce sometimes locks the screen even when lock is disabled
<freemangordon> Wizzup: BTW, most-probably the flickering in lima was because our clutter was missing buffer_age support
<freemangordon> Wizzup: if I pull image builder, is it supposed to work?
<freemangordon> or I have to create some special VM?
<Wizzup> freemangordon: pull can work, but I loathe to use it in general
<Wizzup> freemangordon: I made a sunxi image today
<Wizzup> but it does not have kernel or u-boot
<Wizzup> but everything else is there
<Wizzup> :)
<freemangordon> well, I wonder how iseful it would be without kernel/uboot :)
<freemangordon> *useful
<Wizzup> well, you will have your own u-boot and kernel
<Wizzup> won't you?
<freemangordon> yes, I will
<Wizzup> then :)
<freemangordon> but isn't it better to have at least kernel?
<freemangordon> like, we have different DTBs, but kernel should be the same, no?
<Wizzup> yes, but I am out of time to dedicate to this and the image builder kernel was -broken-
<freemangordon> ah
<Wizzup> so I just disabled it so I could at least get base image
<freemangordon> ugh, u-boot won;t even build on my ubuntu :(
<Wizzup> you might be able to use the old u-boot if you still have the sd card of image
<freemangordon> I still have the tree :)
<freemangordon> just pulled, but stored sha id before the pull ;)
<Wizzup> :)
<freemangordon> now I have to find boot.scr and mkimage parameters
<freemangordon> not that I have sd card to test with :)
<Wizzup> I don't have 3d on the rpi yet, but given that it is a rpi4 and the screen is 800x480, llvmpipe seems to be ok :)
<freemangordon> Wizzup: maybe I can pull image builder and see why kernel is broken
<freemangordon> but I will have to setup some recent ubuntu VM
<freemangordon> or maybe I can use leste?
<Wizzup> all of those can work
<freemangordon> Wizzup: linux-5.11.y
<freemangordon> isn;t that too old?
<Wizzup> yes.
<Wizzup> that too
<freemangordon> hmm, how to build for maemo not for devuan?
akossh has quit [Read error: Connection reset by peer]
<uvos> Wizzup: "it seems that mce sometimes locks the screen even when lock is disabled" what makes you say that?
<Wizzup> I observe it
<Wizzup> it's probably what you discussed with fmg earlier
<Wizzup> it's particularly obvious on both the lime and the raspi since they don't have a power button
<Wizzup> so I can't unlock unless I ssh in and restart mce
<Wizzup> it only happens once after boot, mind you
<uvos> it seams to work fine here
<uvos> what are you seeing exatcly
<Wizzup> the screen turns off and touching it does not make the screen turn on
<Wizzup> and the option to lock the screen is explicitly disabled
<uvos> ok
<freemangordon> and to add to that - mce locks screen on power-up even when keyboard is open
<uvos> dosent happen here so its probubly something in lock-tklock or lack of https://github.com/maemo-leste/osso-applet-display/pull/2
<uvos> freemangordon: mce cant know if the keyboard is open on power up
<uvos> unfortionatly
<freemangordon> how's that?
<uvos> in the fremantle kernel
<uvos> there was a hack that allowed it to read that key via sysfs
<uvos> but we just have evdev
<uvos> that only creates an event when the slide state changes
<freemangordon> oh
<uvos> so mce has no idea about the slide state untill it moves once
<freemangordon> thats....
<uvos> it assumes closed
<freemangordon> I am speechless :)
<uvos> but fear not
<uvos> there is some way to read the key state on startup in the mainline kernel
<uvos> evtest manages somehow :)
<freemangordon> :)
<freemangordon> ok, then we just need to find it
<Wizzup> btw I'm planning to show off a few devices at openfest and have them xmpp chat with each other
<Wizzup> hard on devices with no hwkeyboard but eh
<uvos> bring bluetooth keyboards maybe
<freemangordon> I have one USB, from the tablet :)
<Wizzup> the raspi and lime2 have a usb port
<Wizzup> ;)
<Wizzup> If I ever finished the qt5 im it would not be a problem hehe
akossh has joined #maemo-leste
<uvos> @bug Wizzup
<uvos> but thats still a bug, the gconf key should not have moved in the transition to mce-rtconf, gesttings comapt work, but it probubly changed its name slightly causing this bug
<uvos> probubly need a special case for this key here
<uvos> it probubly ends up in /system/osso/dsm/display/ but should go in /system/osso/dsm/locks/
<uvos> oh wait there is a special case for it allready
<uvos> hmm
<uvos> maybe touchscreen_keypad_autolock_enabled is not the right match, ill check it out some time soon.
<Wizzup> uvos: ty @ check out
<Wizzup> I don't want to introduce bugs in the next 2 days :D
* uvos merges mce dev branch into master and builds
<Wizzup> :D
Twig has quit [Read error: Connection reset by peer]
uvos has quit [Ping timeout: 268 seconds]
vgratian has joined #maemo-leste
dev has joined #maemo-leste
vgratian has left #maemo-leste [#maemo-leste]
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
mardy has quit [Quit: WeeChat 3.5]
akossh has quit [Ping timeout: 268 seconds]
<norayr> wlan stack issue, allows remote execution of code.