<huckg>
Maybe I could write an idiot's guide, I seem to be well qualified.
<Wizzup>
:)
<Wizzup>
rafael2k: I get:
<Wizzup>
[ 4.380262] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,770): error -19
<Wizzup>
[ 4.388491] Please append a correct "root=" boot option; here are the available partitions:
R0b0t1`` has quit [Ping timeout: 240 seconds]
R0b0t1`` has joined #maemo-leste
<Wizzup>
rafael2k: I can't make sense of this
<Wizzup>
-19 is ENODEV?
<Wizzup>
so what, EXT4 is enabled or something?
<Wizzup>
+CONFIG_EXT3_FS=y
<Wizzup>
+CONFIG_EXT4_FS_POSIX_ACL=y
<Wizzup>
..
<Wizzup>
oh they make it a module later on...
<Wizzup>
can we just go back to our config? :(
<huckg>
Do I run expandcard.sh
<huckg>
?
<Wizzup>
huckg: yeah
Pali has quit [Ping timeout: 256 seconds]
<huckg>
resize2fs: not found
<Wizzup>
uhh
uvos has quit [Ping timeout: 256 seconds]
<huckg>
also partprobe and fdkisk not found. First I did su and used toor as password.
<Wizzup>
does /sbin/resize2fs exist
<huckg>
then cd /etc and ./expandcard.sh
<Wizzup>
I usually run /etc/expandcard.sh but it probably does not matter
<huckg>
all of those are in /sbin
<Wizzup>
So you got 'resize2fs: not found' when running the script as root?
<Wizzup>
I guess so, it checks if it is run as root or not
<Wizzup>
how did you do su?
<Wizzup>
try 'su -'
<Wizzup>
or just use 'sudo -i'
<Wizzup>
huckg: yeah that's it I think
<huckg>
simply 'su' no hyphen
<Wizzup>
yes, that seems to not set the correct $PATH
<Wizzup>
the other two options as laid about work
<Wizzup>
laid out above*
<huckg>
ok, did that, it seemed to work, now device is unresponsive
<huckg>
on reboot stuck on KEXECBOOT screen, doesn't respond
<Wizzup>
I think there is an occasional hang in kexecboot where it doesn't work
<Wizzup>
power + volume min resets
<Wizzup>
(hold it)
<Wizzup>
I don't know why it happens on bionic, I don't have it on the droid3 kexecboot
<huckg>
ok, second reboot working
<Wizzup>
btw, there's a lot of good stuff coming to stable updates soon :)
<Wizzup>
much faster 2d
<huckg>
happy to be your guinea pig.
<Wizzup>
:)
<Wizzup>
few days
TonyStone has quit [Read error: Connection reset by peer]
huckg has quit [Quit: Client closed]
_inky has quit [Quit: Leaving.]
<Wizzup>
weird kernel build was much faster now
TonyStone has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
xmn has joined #maemo-leste
rafael2k has quit [Quit: BitchX: stays crunchy in milk!]
System_Error has quit [Ping timeout: 276 seconds]
mardy has joined #maemo-leste
macros_ has quit [Ping timeout: 240 seconds]
joerg has quit [Ping timeout: 240 seconds]
macros_ has joined #maemo-leste
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 256 seconds]
<tmlind>
freemangordon: so based on my initial quick hacks looks like adding int drm_fd to the end of struct _dbm_device and opening and using it instead of the render node for buffer allocation the related wlroots hacks can be dropped :)
<tmlind>
so drm_fd is looked up with drmGetPrimaryDeviceNameFromFd(dev->fd)
<tmlind>
maybe this issue also goes away with your planned buffer changes?
<tmlind>
so the issue is that some operations are not allowed for the render nodes
<tmlind>
anyways, will tinker more with it tonight
<freemangordon>
tmlind: I don;t know how those render nodes are supposed to work, so no idea if it will help
<freemangordon>
but, basically I plan to move to omap GEM buffers from DUMB biffers
<freemangordon>
that will allow me to set TILER flag on scanout buffers, which in turn shall allow setting "rotation" property on the relevant planes
rafael2k has joined #maemo-leste
<rafael2k>
Wizzup: kernel works, not only me using, but all mobian users...
<rafael2k>
Wizzup: did you copy over the new dtbs? btw, my pp is the 1.2 hw rev
<rafael2k>
morning!
<freemangordon>
rafael2k: morning!
<freemangordon>
tmlind: also, if we move to gbm BOs in omap DDX it may turn out that "export non-linear buffers" patch is not needed as it seems pvr_dri_support allocates directly from pvr driver for non-scanout buffers
<freemangordon>
tmlind: oh, and libdbm from ddk 1.9 is using omap_bo functions, I wonder why did they moved to dumb buffers later on
<tmlind>
freemangordon: no idea, but why do we even need libdbm? why not do this directly in mesa?
<freemangordon>
because of the closed pvr_dri_support blob which calls into this
<tmlind>
uhh
<freemangordon>
:)
<tmlind>
anyways, looks like the nastiest wlroots hack can be dropped with some libdm changes :)
<tmlind>
i'm now seeing display not come back up after blanking though, not sure if my changes somehow caused that
<freemangordon>
make sure to pull latest code as I fixed a nasty use-after-free bug I introduced with REing
<tmlind>
ok, need to go now, bbl
<freemangordon>
bbl
rafael2k has quit [Ping timeout: 240 seconds]
rafael2k has joined #maemo-leste
rafael2k has quit [Ping timeout: 240 seconds]
rafael2k has joined #maemo-leste
rafael2k has quit [Ping timeout: 240 seconds]
rafael2k has joined #maemo-leste
rafael2k has quit [Ping timeout: 240 seconds]
rafael2k has joined #maemo-leste
Pali has joined #maemo-leste
<rafael2k>
I realize the new pp kernel is already in the repo!
<rafael2k>
ok, initrd was not created after new kernel installed (through apt-get upgrade)
<rafael2k>
and yes! 5.15.10 from the repo boots fine! yay!
<rafael2k>
but the initrd not being automagically created and copyed to correct path needs to be fixed
<rafael2k>
I don't really know what happened in the recent batch of maemo updates, but I'm getting a strange 3G icon instead of 4G
<rafael2k>
and no strenght bars
<rafael2k>
Linux devuan-pinephone 5.15.10 #1 SMP Tue Jan 11 00:53:27 UTC 2022 aarch64 GNU/Linu
<rafael2k>
; )
<rafael2k>
but the kernel seems all good
<rafael2k>
so now we have telephony back to PP! with new ofono, also voice calls!
uvos has joined #maemo-leste
<uvos>
Wizzup: bionic dossent reboot with the power+vol key presses
<uvos>
Wizzup: none of the mapphones older than xt894 do this
uvos has quit [Remote host closed the connection]
uvos has joined #maemo-leste
<rafael2k>
btw, forget about the telephony icon - it all works great in latest kernel - I just was in a place without signal...
<uvos>
we dont use initramfs btw
<rafael2k>
I use
<rafael2k>
:P
<uvos>
so nessecary modules have to be built in
<uvos>
yeah thats why its broken
<uvos>
you added a kernel config
<uvos>
that dosent have enough modules to mount the fs
<rafael2k>
sure
<uvos>
and work around it with initramfs
<rafael2k>
initramfs has all the modules to boot
<rafael2k>
this is why it exists in the first place...
<rafael2k>
why no initd, btw?
<uvos>
this makes sense on x86 pcs
<uvos>
where you have one kernel for very different hw
<uvos>
so a image with all the modules needed to get to mounting the fs is large
<rafael2k>
this is the idea for arm too
<rafael2k>
with device trees, dtbs and so on
<uvos>
with a kernel that only works for one device anyhow its not needed
<rafael2k>
there are many reasons of why to use a kernel module, but anyway, got it
<rafael2k>
so some modules need to be sneaked in with 'y'
<uvos>
yes
<Wizzup>
uvos: oh
<rafael2k>
and I'll need to update my boot.txt
<Wizzup>
rafael2k: we do not have an initrd in our package, which is why the previous kernel failed
<Wizzup>
rafael2k: it must work without initrd or we need to make initrd
<rafael2k>
did not failed for me :P
<Wizzup>
yes because I rebuilt and fixed the package so that EXT4 is built in
<Wizzup>
it was a module and therefore my pinephone can't mount its rootfs atm
<rafael2k>
nope, I just created an initrd
<Wizzup>
that's not the point
<rafael2k>
anyway, easy pizzy
<Wizzup>
'apt dist-upgrade' gives nobody an initrd on leste
<rafael2k>
I did not know that, sorrio
<Wizzup>
so any upgrade will break if the required modules aren't built in
<Wizzup>
does the current kernel package work without initrd for you?
<Wizzup>
(M iade ext4 built in)
<Wizzup>
I made*
<rafael2k>
I dunno, I was always creating an initrd
<rafael2k>
but it is not only ext4 right?
<rafael2k>
how would one use use a luks root fs this?
<rafael2k>
then you would need crypto stuff too, md stuff, and so on
<Wizzup>
I don't know what else besides ext4 is required to boot
<Wizzup>
luks is always done with an initrd
<rafael2k>
it depends on the use case
<Wizzup>
I am not -against- an inird but we never needed it up to this point, and ext4 being a module is not a good reason
<Wizzup>
of course when we add luks support, we will need them
<rafael2k>
ok, I don't really see the point in not truggering update-initrd after a kernel upgrade
<rafael2k>
but it is an easy change anyway
<Wizzup>
are those scripts even installed in leste pp?
<rafael2k>
I'd like to see my root fs ciphered soon
<rafael2k>
yes
<Wizzup>
I am not so sure they are on mine, because I don't think an initrd was made
<uvos>
non
<uvos>
no they arnt
<Wizzup>
you probably just did something to your image to get it rafael2k
<rafael2k>
lemme see the packages
<rafael2k>
no
<rafael2k>
all from the repo
<rafael2k>
my system is clean
<Wizzup>
our repo is debian :)
<rafael2k>
yeap
<Wizzup>
initrd will require us to think a lot of things through that we're not really ready for I think, so we've been postponing that until we really need it
<rafael2k>
but it could, right? in case we want to add security as an option
<Wizzup>
11:33 < Wizzup> initrd will require us to think a lot of things through that we're not really ready for I think, so we've been postponing that until we really need it
<rafael2k>
which things exactly?
<Wizzup>
let's see "can we do luks" separate from "get proper pine64 kernel"
<rafael2k>
sure!!
<rafael2k>
and one step of the other
<rafael2k>
; )
<Wizzup>
I am pulling the new image now on a fresh image with -devel added
<Wizzup>
let's see if I get an initrd
<rafael2k>
I can test here too
<rafael2k>
without any manual intervention
<Wizzup>
the thing with luks and initrd is that we might even want some ui in there, touchscreen, on screen keyboard to enter unlock codes, etc
<Wizzup>
and we also need to think about alarms, other stuff
<Wizzup>
so I doubt it'll be as simple as installing 'cryptsetup-initramfs'
<Wizzup>
also we have various modes we (can) boot to like recovery mode with on screen keyboard
<rafael2k>
now with hardware keyboard in the pine, already supported by the kernel...
<Wizzup>
I don't have a hw keyboard for mine yet, and our general solution should work for devices without hw keyboard
<Wizzup>
(mine is being shipped, but yeah)
<rafael2k>
if you want luks, find yourself a keyboard, or copy the initd from postmarket OS (which has on-screen keyboard and so on to unlock luks rootfs)
<Wizzup>
no, I want luks the proper way :P
<Wizzup>
that was not the point
<rafael2k>
the standard way is the proper way
<rafael2k>
:P
<rafael2k>
yeap
<bencoh>
wait, what would be the proper way?
<Wizzup>
well then I guess you can run xfce on your phone and hope for the best :P
<rafael2k>
luks is support for long time in debian, I just for decades
<rafael2k>
it works fine as it
<rafael2k>
*as is
<Wizzup>
I think we are miscommunication very often
<bencoh>
Wizzup: how do you expect it to boot with a luksed rootfs and no initrd?
<Wizzup>
bencoh: I did not say that
<bencoh>
I thought so as well, but then ... what's the proper way? (or rather, what isn't the proper way?)
<Wizzup>
rafael2k: I am not questioning how well luks works in debian, I am saying that I don't think a tty and 'use hw keyboard' is a good way, some on screen keyboard is required, and probably way more integration
<Wizzup>
rafael2k: so whether and how debian supports it is not super relevant, debian is built for servers
<Wizzup>
bencoh: well clearly with initrd, but not just 'oh copy this initrd from source X' :)
<bencoh>
ah :)
<bencoh>
I wonder if a framebuffer app would cut it
<Wizzup>
how would maemo alarm work?
<rafael2k>
Wizzup: Debian is built for server? Did not know that. :P
<bencoh>
Wizzup: ah, right
<rafael2k>
btw, I can work in copying over the on-screen keyboard from PmOS
<Wizzup>
rafael2k: still kernel does not boot for me
<bencoh>
meaning we'd need a fullblown xorg-capable initrd anyway
<rafael2k>
when we have the more urgent stuff settle down
<Wizzup>
bencoh: yes
<bencoh>
(not just xorg-capable, but hildon-capable)
<bencoh>
sounds like a lot tbh
<Wizzup>
bencoh: well there are other things we can do, but these are things to consider when I say "I want luks the proper way"
<bencoh>
yeah
<rafael2k>
bencoh: x on initrd? no
<Wizzup>
layman translation would be "I don't want to miss my flight because my phone was stuck in on screen keyboard to unlock my luks partition and thus could not make an alarm sound"
<bencoh>
:]
<Wizzup>
rafael2k: ok now both my pinephone sd cards are bricked wrt kernel
<rafael2k>
Wizzup: you need to light a candle
<Wizzup>
we could have the pinephone use debian initrd I suppose, but it could get in the way of many things
<Wizzup>
like probably it will come with systemd in the initrd
<rafael2k>
I don't really get this maemo stack part
<bencoh>
either that, or add a tiny framebuffer-only alarm app for actdead/alarm-mode
<Wizzup>
that can mess up things for us
<rafael2k>
what is this alarm thing you are talking about?
<uvos>
rafael2k: phone is off
<uvos>
rafael2k: alarm fires
<uvos>
rafael2k: what happens?
<uvos>
rafael2k: phone is off
<bencoh>
(alarm, as in, wakeup-wakeup-time-to-wakeup)
<uvos>
rafael2k: user plugs in usb charger
<uvos>
rafael2k: what happens?
<Wizzup>
rafael2k: care to send over the initrd you made for the latest kernel pkg
<uvos>
yes replacing the mess of "actdead" with small framebuffer applicatiosn is something imo we need to do
<uvos>
its also what im doing allreay
<uvos>
see charge-mode
<Wizzup>
well that could work, but there are also other ways to do deal with it
<Wizzup>
there could also be a (read-only by default, forced by crypto) partition which we boot from
<Wizzup>
I think the chromebooks use some dm thing for this - dm verity?
<uvos>
i gues, but the way actdead is implemented its pretty terrible, so reimplementing how it works is a good thing
<Wizzup>
I think this is unrelated to how actdead works
<uvos>
sure
<uvos>
you could place small framebuffer application(s) into readonly rootfs
<Wizzup>
rafael2k: so point is that "phone is not a server and fullfills some other needs that typical initrd does not deal with"
<Wizzup>
rafael2k: could you send me the initrd from your device so that I can maybe rescue one of my devices?
<Wizzup>
uvos: or X if we are lazy and want to re-use code
<uvos>
yes but the curreny code is a huge maintiance bruden because its so bad
<uvos>
(spread over all of the deamons)
<uvos>
with if(actdead) changing deamon behavior
<Wizzup>
we don't even have alarms working yet, I think because of pulseaudio setup
<Wizzup>
I don't know if it's that bad really, but I haven't looked at it in a while
<uvos>
Wizzup: it really is that terrible, so it works by having the entire stack runing, changings its behavior all over the place, this is really bad allready beacuse this means that actdead implementation (a mode that really dosent do mutch at all) is spread over manny manny thousands of lines of code for no reason. then it causes a masive burdon of code in all of these unrelated applications that cant really be tested, because you cant
<uvos>
just test these codepaths in a single deamons in isolation so you have to spin up actdead on the entire device an poke around, but good luck finding bugs because all of these deamons in freshly untested codepaths interact via dbus so who knows who causes what.
<uvos>
its basicly as bad as the entrie rest of the system in complexity
<uvos>
for providing functionality that could be in a 1klock frambuffer application
<Wizzup>
yeah, I'm not saying we should do this for alarm, I mostly do not have a grasp on the complexity of it so will refrain from commenting
<uvos>
not to even mention the insanity of booting all the way to x with most deamons runing just to display a battery icon
<Wizzup>
I think first steps alarm wise is to make sure that our audio setup works the way it expects (with roles) and then see if normal alarms (nevermind 'wake-to-alarm') works
<uvos>
normal alarms work in the sense that alarm mode is enterd and the alarm shows up
<uvos>
so dose wake to alarm btw
<uvos>
except that rtc isent set
<uvos>
everything else is in place
<Wizzup>
uvos: sounds also don't work
<uvos>
(except also that it boots to hildon and shows the alarm there ofc)
<uvos>
yes
<Wizzup>
and the vibration doesn't work because the sound doern't work
<uvos>
yes
<uvos>
i mean it goes thrugh the motions mostly
<Wizzup>
right
<Wizzup>
freemangordon: ftr looks like normal mc places accounts in $HOME/.local/share/telepathy/mission-control/accounts.cfg
<Wizzup>
vs $HOME/.rtcom-accounts on fremantle
<Wizzup>
I bet that noia patched mc to read from that dir
<Wizzup>
nokia*
<uvos>
seams like mostly nonsese obfuscation or?
<Wizzup>
I wouldn't go so far to say thatr
<Wizzup>
I'm just trying to understand who stores what, reads/writes what to where
<uvos>
ok
<Wizzup>
the file format/config is exactly the same, so it looks like just a changed path
<Wizzup>
fremantle also has accounts.cfg in .rtcom-accounts
<Wizzup>
so this means that probably indeed telepathy and mc (mission-control) manage accounts for us, and rtcom doesn't do special things there to 'register' accounts or something
<Wizzup>
I mean rtcom clearly does some things in conversations and calls ui, but they don't add accounts to telepathy by parsing .rtcom-accounts/accounts.cfg for example
<Wizzup>
which is good to know conceptually
<uvos>
sure
<rafael2k>
Wizzup: entered in a working meeting - come back soon
<Wizzup>
np
<Wizzup>
uvos: do you think we're ready to start pushing 5.15 to stable?
<Wizzup>
I think there might be -some- issues we haven't run into yet in -devel, but otherwise we're pretty good?
<Wizzup>
freemangordon: same question to you^
<Wizzup>
I suppose I should test one more "download latest image" and try "apt dist-upgrade" to -devel type of action
<uvos>
i hangs often for me
<uvos>
its allways pretty stable @home
<uvos>
as soon as i take it outside it starts rebooting every 10 minutes or so if in use in any way (audio etc)
<Wizzup>
really?
<uvos>
yeah
<Wizzup>
on the droid4?
<uvos>
yeah
<Wizzup>
interesting...
<Wizzup>
I really haven't seen any resets/hangs for a week+
<rafael2k>
btw, this also can be used as the scheleton for the multi-boot boot.txr
<rafael2k>
*boot.txt
<rafael2k>
edit the boot.txt, and do the mkimage
<rafael2k>
Wizzup: this is why multi-boot is good
<rafael2k>
; )
<rafael2k>
if one does not boot, boot the other system
<Wizzup>
much better is not to break the system
<rafael2k>
totally agree
<rafael2k>
The system is broken for more than one year
<rafael2k>
we are trying to unbreak, right?
<Wizzup>
we're trying to fix bugs yes, it was not usually in an unbootable state, but this is fine, it's -devel anyway
<Wizzup>
I'm just trying to understand we never "removed" initrd, it was just never necessary
<Wizzup>
so saying "it was not me who removed initrd from maemo" is just weird
<rafael2k>
Im just kidding
<Wizzup>
it's booting now btw
<Wizzup>
ok
<Wizzup>
uvos: heh I am greeted by salutem
<Wizzup>
rafael2k: so we have two options: (1) we make a less bloated config and also remove all the parts where we make the stuff that we need modules (this could just be removing some mobian patches) or (2) we have pine64 kernel package depend on initrd tools and hope the stuff runs automatically
<Wizzup>
(2) also means we have to update our uboot package
<Wizzup>
If we do (2) the nice thing is we can just piggy back on mobian kernel, which is fine by me
<rafael2k>
Is the config bloated?
<rafael2k>
I don't get it
<Wizzup>
debian configs usually are bloated yeah
<rafael2k>
wait
<rafael2k>
you was saying about booting
<rafael2k>
now about bloat?
<Wizzup>
it's the same thing: we need to change the pine64_config
<rafael2k>
same thing?
<rafael2k>
hum
<rafael2k>
ok
<rafael2k>
I don't see any bloat tbh
<rafael2k>
it is just a pretty standard setup
<rafael2k>
does it harm?
<Wizzup>
ultimately yes, but it's not particularly important now
<rafael2k>
I thought we just needed to add some modules as static and voila
<Wizzup>
the kernel build took like 4 hours yesterday
<rafael2k>
yes?
<Wizzup>
as opposed to like 1hr for droid4
<Wizzup>
but it seems to vary, so idk
<rafael2k>
of course yes... not having half of the functionalities of linux - definitelly
<Wizzup>
yeah so if we want to go for (1) then we need to figure out what stuff needs to be built in
<rafael2k>
ok
<Wizzup>
yesterday I tried to just make EXT4 builtin, but that wasn't enough to make it boot
<rafael2k>
I can do that
<rafael2k>
I'll try to do it today at night, after baby goes sleep
<Wizzup>
I would really appreciate that if you can, we could just add another patch on top of the mobian patches to changef pine64_defconfig
<Wizzup>
awesome
<rafael2k>
sure
<Wizzup>
if that ends up being too frustration, we can go for (2) as far as I am concerned
<rafael2k>
no no
<rafael2k>
lets do the fast track now
<Wizzup>
re: bloat, you're right the on-disk is about the same d4 and pine64, so maybe the raspi build setup was just struggling more initially
<rafael2k>
to have everything up and running
<rafael2k>
just set some 'y' and that is it
<Wizzup>
ok so you want me to install initramfs-tools ?
<Wizzup>
wait, I don't understand
<Wizzup>
what is "fast track"?
<rafael2k>
just edit the config
<rafael2k>
and have a kernel config which boots without initrd
<rafael2k>
as is in maemo right nnow
<Wizzup>
ok, and you can take a look at that?
<rafael2k>
yes
<Wizzup>
ok, ty
<rafael2k>
I come back later
<rafael2k>
lemme know about ofono too
<rafael2k>
if there are any questions, lemme know
<rafael2k>
I saw updated sphone
<rafael2k>
cool!
rafael2k has quit [Quit: BitchX: not to be taken internally]
<Wizzup>
looks like I had initramfs-tools already installed, so why did it not run... hm
<freemangordon>
Wizzup: I am not sure I can help with mc/tp stuff, it passed more then an year I played with it
<freemangordon>
re kernel - do you still see xorg crashes after latest patch?
<freemangordon>
BTW I had very strange behaviour twice, in different ways
<Wizzup>
no, I have not seen X crashes
<freemangordon>
first time device was in my pocket with this maps application searchiong for gps
<freemangordon>
maybe 30 minutes later as was unable to unlock the device - swiping tklock slider was doing nothing
<Wizzup>
the latter sounds like the drm thing I ran into
<Wizzup>
or did tklock show for you?
<freemangordon>
yes, it was there
<freemangordon>
and wotking
<freemangordon>
I was able to swite the slider
<Wizzup>
the power button might trigger more easily
<freemangordon>
hmm?
<freemangordon>
power button triggers tklock
<Wizzup>
I was thinking about the maps app
<Wizzup>
not sure about either bugs
<Wizzup>
I don't think I have seen those beforfe
<freemangordon>
me neuther
<freemangordon>
*neither
<freemangordon>
either mce or systemui was misbehaving
<uvos>
never seen that befor either
<uvos>
then again i dont use tklock
<uvos>
yeah that sounds like systemui and mce got out of sync
<uvos>
global state flags wise
<uvos>
maybe mce crashed
<freemangordon>
but, given that systemui/tklock have not been changed since long time ago I would say mce got out of sync, somehow
<freemangordon>
could be
<uvos>
and got restarted
<uvos>
then its in the wrong state
<freemangordon>
mce should unlock the device on start
<freemangordon>
at least this was the behaviour back then
<uvos>
sure, it dose
<freemangordon>
not really as eventually I had to har-reset (power+vol)
<freemangordon>
*hard-reset
<uvos>
well it dose internally
<uvos>
so probubly not a crash then
<freemangordon>
mhm
<freemangordon>
another very weird thing that happened is something with touchscreen
<uvos>
it dident work?
<uvos>
thats hw bug
<uvos>
also happens on android
<freemangordon>
could be
<freemangordon>
happened only once
<freemangordon>
it was semi-working
<freemangordon>
like some touches were registered some not
<uvos>
hw bug
<freemangordon>
could be
<uvos>
very sure
<freemangordon>
I am reporting re Wizzup's question if we shall push to -stable
<freemangordon>
and the most annoying thing is that charging stuff
<uvos>
right and a hw bug is no reason not to
<freemangordon>
sure
<Wizzup>
:)
<uvos>
the charging stuff is fine for me
<uvos>
except the ocassional delay
<freemangordon>
not for me
<uvos>
so whats the probel exacly
<uvos>
please describe in extream detail
<freemangordon>
that occasional delay happens 90% if not more of the cases here
<freemangordon>
sec
<freemangordon>
after I plug a cable, led turns green, but no charging notification is giver neither battery icon is animated
<freemangordon>
no idea what the 'delay' you talk about is, but it sits like that here forever
<uvos>
havent seen that
<uvos>
but ok
<freemangordon>
happens every time
<uvos>
same bug as the 30s delay
<freemangordon>
do you want me to provide some logs?
<uvos>
can you check sysfs in this state?
<freemangordon>
sure
<freemangordon>
what in particular?
<uvos>
freemangordon: so please:
<uvos>
cat /sys/class/power_supply/battery/uevent
<uvos>
udevadm monitor
<uvos>
plug in usb
<uvos>
cat /sys/class/power_supply/battery/uevent
<uvos>
pastbin output
<freemangordon>
ok, now I have the cable disconnected and battery icon is animated :)
<freemangordon>
so I am nit sure I can do what you want me to
<uvos>
do the above
<freemangordon>
oh, it is even better
<uvos>
and note the state of the gui inidcator at eatch step
<freemangordon>
if I plug the cable, battery animation stops
<freemangordon>
ok, now I have cable connected and no animation, sec will provide the output
<tmlind>
freemangordon: your mesa changes dropped PVRDRIQueryDmaBufFormats PVRDRIQueryDmaBufModifiers PVRDRIQueryDmaBufFormatModifierAttribs, are these not implemented in the firmware or dropped by accident?
<freemangordon>
uvos: I don't think this is upower problem :)
<uvos>
yeah
<freemangordon>
POWER_SUPPLY_STATUS=Discharging
<uvos>
but thats really wierd
<uvos>
since the kernel has it as the last set porparty
<uvos>
in the uevent file
<uvos>
hmm
<tmlind>
freemangordon: if dmabuf modifiers are not implemented then we need to also do what xcracer did and not advertise EXT_image_dma_buf_import_modifiers at all, at least wlroots will bail out otherwise
<freemangordon>
tmlind: I don't think this is adretised
<freemangordon>
oh, it is :(
<freemangordon>
why?
<tmlind>
freemangordon: maybe that commit got accidentally reverted, see 4f851d108e8f ("egl_dri2: Don't expose EXT_image_dma_buf_import_modifiers")
<uvos>
freemangordon: wierd
<freemangordon>
no, changing DRI_IMAGE version should prevent this being advertised
<uvos>
freemangordon: i also cant repoduce the problem
<freemangordon>
uvos: ok, but this happens every time
<freemangordon>
which kernel?
<uvos>
leste
<uvos>
devel
<uvos>
with my patch ofc
<freemangordon>
Linux devuan-droid4 5.15.2 #1 SMP PREEMPT Sat Jan 8 23:05:00 UTC 2022 armv7l GNU/Linux
<uvos>
yeah
<freemangordon>
tmlind: gimme some time to finish what we do with uvos and I'll have a look
<tmlind>
freemangordon: yeah sure no hurry, just wondering.. maybe DRM_IMAGE version gets checked too late when using the extension
<tmlind>
anyways, so i got wlroots working with pretty much just xcracer's modified patch for GL_EXT_unpack_subimage only :)
<freemangordon>
uvos: but "POWER_SUPPLY_STATUS=Charging" in /sys/class/power_supply/battery/uevent
<uvos>
freemangordon: wierd
<freemangordon>
oh
<uvos>
im also not sure how my patch breaks it
<freemangordon>
sec
<uvos>
since it seams to report it the same way
<freemangordon>
yeah, I don;t think it is your patch really
<freemangordon>
yes, but this state could have been set earlier
<uvos>
then we ++ichrg_current
<uvos>
and then ichrg_current == ichrg
<uvos>
so yeah
<freemangordon>
before you start delayed work
<uvos>
should run
<uvos>
if the state is set erlier
<uvos>
either it was set to POWER_SUPPLY_STATUS_CHARGING
<uvos>
and we have nothing to do
<freemangordon>
my point
<uvos>
or its set to something else and POWER_SUPPLY_STATUS_CHARGING is set
<uvos>
freemangordon: so?
<uvos>
btw nothing else in the driver sets this state
<freemangordon>
that it is set to POWER_SUPPLY_STATUS_CHARGING earlier, but while the current was still too low, so FW reported discharging
<uvos>
fw dosent report anything
<uvos>
or framework
<freemangordon>
fw == framework
<uvos>
sure maybe thats what happens
<uvos>
but framweork then later changes the state back to POWER_SUPPLY_STATUS_CHARGING
<uvos>
as evidenced by sysfs
<uvos>
so it should report an event then
<freemangordon>
no, it just reads the current state
<freemangordon>
no
<freemangordon>
no, why event?
<freemangordon>
sysfs is just a representation of the state
<freemangordon>
nobody tracks if there is a chage
<freemangordon>
*change
<freemangordon>
it is driver that shall say "my state has changed"
<uvos>
sure
<uvos>
and it dose
<uvos>
if fw rejects this
<uvos>
it should tell the driver
<uvos>
or report later if the rejection changes
<freemangordon>
maybe it is a corner case not considered
<uvos>
otherwise how shal the driver know it has to report again
<freemangordon>
state == charging with current > 0
<uvos>
but then it needs to poll
<uvos>
it cant do that
<freemangordon>
exactly
<freemangordon>
that's why the driver shall raise an event
<uvos>
it dose
<freemangordon>
I think it does not
<uvos>
when it enables charging
<uvos>
thats the only time it can
<uvos>
wihtout polling
<freemangordon>
yes, but it is too early then
<uvos>
yeah but
<uvos>
it might never be late enough
<freemangordon>
no, you have delayed work
<uvos>
how should the driver know
<uvos>
the current usage might simply be to high for the next 10 minutes
<freemangordon>
see, I don;t think you can report state == charging with positive current
<freemangordon>
that's my point
<uvos>
right
<uvos>
but if so
<freemangordon>
it does not make sense
<uvos>
i dont se how the driver can make it work
<freemangordon>
Pali: ping
<Pali>
pong
<freemangordon>
Pali: do you know, in theory, is it allowed/sane to report battery state as "charging" and "current now" saying that battery supplies energy?
<uvos>
so udev gets an event that somthing changes
<uvos>
and reads it
<uvos>
and but cpcap-battery reports no
<uvos>
so the fix is to check with cpcap-charger what it thinks should be happening
<uvos>
not the "real" state
<uvos>
otherwise it cant work
<uvos>
without polling
<uvos>
it probubly fails for you because your usb cable is high inductiviy or something
<freemangordon>
uvos: so, at the moment udev receives "charging" event, "current now" is still announcing "discharging"
<uvos>
yes
<uvos>
beacuse cpcap-battery reports
<uvos>
in the line linked above
<uvos>
not current now directly
<freemangordon>
come on, the cable is perfect
<uvos>
but battery state sysfs file
<uvos>
freemangordon: sure its fine but it dosent happen here
<freemangordon>
actually thi is my best cable
<uvos>
freemangordon: so the differens is electrical most likely
<uvos>
anyhow
<freemangordon>
uvos: and? because it works for you that means we can leave it like that or what?
<uvos>
no
<uvos>
wtf
<uvos>
anyhow cpcap-charge must allways report charging in state sysfs file (not in current that dosent mattter) when cpcap-charger has enabled charging
<uvos>
anyhow cpcap-battery must allways report charging in state sysfs file (not in current that dosent mattter) when cpcap-charger has enabled charging
<freemangordon>
ok, so, how is "current too high" detected?
<freemangordon>
I guess someone polls
<uvos>
yeah
<freemangordon>
ok, that's fine
<freemangordon>
ok, so, do you want me to put printks somewhere?
<uvos>
no its fine
<uvos>
we know why it happens
<freemangordon>
umm, lemme read it again, as I am not sure I know
<uvos>
unfortionatly having the state sysfs file follow current (ie real charging vs discharing) state is impossible without polling in kernel
<uvos>
without breaking events
<uvos>
so we have to make it show intended state not real state
<freemangordon>
that's fine I guess, as this polling happens only when charger is connected
<uvos>
no
<uvos>
you would have to poll also while discharging and connected
<uvos>
i dont think thats fine
<uvos>
at all
<freemangordon>
uvos: so, "charging" here means "charging connected", right?
<uvos>
yes so charging in the sense that the charging registers are enabled
<uvos>
this is different from connected
<uvos>
and from current state
<freemangordon>
ok, I still fail to understand why it does not work then.
<freemangordon>
uvos: also, lets forget about sysfs
<freemangordon>
it is not related to events
<uvos>
it is
<freemangordon>
how's that?
<uvos>
udev gets a changed event
<freemangordon>
and reads sysfs?
<uvos>
and then reads sysfs to get what it changed to
<uvos>
iiuc
<freemangordon>
I think event itself contains the change
<freemangordon>
but not sure
<freemangordon>
I guess I can strace
<Wizzup>
udev listens on netlink which probably already contains some info, but they are closely linked
<freemangordon>
Wizzup: the point is that information comes with the event
<freemangordon>
you don;t just receive "something changed"
<freemangordon>
no?
<Wizzup>
yes, over netlink
<freemangordon>
exactly
<Wizzup>
I would assume kernel makes drivers able to change both sysfs and netlink events at once though, so they should be linked
<freemangordon>
and because the initial event comes at the very beginning, either state is still "discharging" (as we are about to ramp-up) or the current is not ok
<uvos>
no
<uvos>
it comes at the end
<freemangordon>
uvos: where from?
<uvos>
its reported at the end by cpcap-charger
<uvos>
in the delayed work funciton
<freemangordon>
end of ramp-up?
<uvos>
i made sure to change the state at the end of ramp-up
<uvos>
but ofc
<freemangordon>
hmm
<uvos>
current might still be negative
<uvos>
since its an avg
<uvos>
over some length
<freemangordon>
ok, lemme see what is reported
<freemangordon>
uvos: ah, I see
<freemangordon>
uvos: isn't it better to delay status report?
<uvos>
no
<uvos>
beacuse what happens if the device is loaded
<uvos>
you dont know how long oyu need to delay
<freemangordon>
right
<freemangordon>
but, how you want me to change that?
<freemangordon>
if (cpcap_battery_cc_get_avg_current(ddata) < 0) I mean
<freemangordon>
this makes sense
<uvos>
just report the state of CPCAP_REG_CRM instead of current in POWER_SUPPLY_PROP_STATUS
<uvos>
current sure makes sense
<uvos>
but we cant make it work
<uvos>
i dont see how
<freemangordon>
ok, lemme think about this for a while
<freemangordon>
uvos: that's how: on ichrg_current == ichrg, schedule HZ/10 delayed work and report POWER_SUPPLY_STATUS_CHARGING on that scheduled work
<freemangordon>
that way avg will have time to settle
<freemangordon>
ofc if you have 2 cores spinning 100%, udev will see discharging, but not much we can do
<freemangordon>
shall I do that patch and test it here?
<uvos>
no
<uvos>
thats terrible
<uvos>
so what happens if right at 10 sec theres a usage spike?
<uvos>
of current
<uvos>
er 1/10 second
<uvos>
also what happens if the user just enables charging with 200mA or whatever
<uvos>
you have to just report the state of CPCAP_REG_CRM instead of current in POWER_SUPPLY_PROP_STATUS
<uvos>
please also check what other drivers so
<uvos>
*do
<uvos>
n900
<uvos>
acpi
<freemangordon>
uvos: sorry, don;t get it
<freemangordon>
you only changed how charge current is applied - immediately vs ramp, right?
<uvos>
yes
<freemangordon>
so, what I propose will fix the issue caused by that chagne
<freemangordon>
if there is some general issue with status reporting, that's another story
<freemangordon>
and we shall report on ML
<uvos>
it was wrong before to
<uvos>
it just happend to work
<freemangordon>
exactly
<uvos>
but if you report the state of CPCAP_REG_CRM instead of current in POWER_SUPPLY_PROP_STATUS
<freemangordon>
but this driver has a maintainer, no?
<uvos>
its fixed
<uvos>
tmlind:
<uvos>
and me
<uvos>
really
<freemangordon>
what is CPCAP_REG_CRM?
<uvos>
target current
<freemangordon>
will we have "using too much power" notifications?
<uvos>
i dont know, depends on if it checks status or current
<freemangordon>
because this was definitely working
<freemangordon>
and I am afraid we will break it
<uvos>
yeah but you cant have status reflect real current
<uvos>
and not have the event be a random number generator
<uvos>
its impossible
<uvos>
unless you poll
<freemangordon>
also, I think we have this 500 mA limit issue as well. if our budget is 1.5A then we won;t have those problems I guess
<uvos>
thats just hiding it
<uvos>
also you can acivate 1.5a
<uvos>
i do
<uvos>
its just not safe to do generally
<freemangordon>
mhm
<uvos>
besides its still a problem with 1.5a
<uvos>
gues who plugs in there phone with sgx and cpu fully loaded
<uvos>
?
<uvos>
absolutly everyone who plays games on mobile devices
<uvos>
we cant switch to and away from that without polling
<freemangordon>
uvos: still, POWER_SUPPLY_STATUS_NOT_CHARGING is the correct status to report if charger is connected but it cannot supply enough current, no?
<uvos>
yes
<uvos>
but we cant do that
<freemangordon>
why?
<uvos>
since we dont have irq to tell us when real current passes 0
<freemangordon>
are you sure?
<freemangordon>
as this does not make sense
<freemangordon>
maybe it is not enabled
<uvos>
well the chip isent documented
<freemangordon>
I guess we dont; have docs
<uvos>
if so moto dosent use it
<freemangordon>
OTOH I don;t see any problem to poll when on charger
<uvos>
not sure how that interacts with inductive charging
<sicelo>
tmlind: nice @ wlroots. I must try sway again on my n900
<sicelo>
You guys are busy and I don't want to interrupt, but I was going to ask where/how to see the charge mode in action, as I haven't seen it yet
<uvos>
should work on mapphones
<uvos>
in devel
<uvos>
if you boot with usb pluged in
<sicelo>
How?
<sicelo>
I'm testing on a mapphone
<uvos>
have the device off
<uvos>
plug in a usb cable
<uvos>
should be sufficant
<sicelo>
Mine boots leste
<uvos>
check if you charge-mode in cmdline
<uvos>
but should be in devel
<uvos>
but if you changed boot.cfg it wont update
<sicelo>
I'm always in -devel
<uvos>
so whats you cmdline?
<sicelo>
It's rebooting. Will see when it's back up
<sicelo>
Mmm, bootloop, heh
<sicelo>
Okay now looks like my new battery is broken :'(
<sicelo>
Maybe I'm hitting the same issue fmg is ... no idea.
* sicelo
gets his power back ... the d4 usually seems happier with it
<sicelo>
*bank
<sicelo>
No luck with this too. Back to Android charging. At least that works, so yeah ... appears I'm facing what issue fmg faces
<uvos>
right
<uvos>
its one and the same issue
<uvos>
the device will shutdown if it enters hildon with the battery to low but it should never get there
<uvos>
it should stay in charge mode
<uvos>
so for some reason yours isent
<uvos>
probubly because you at some point touched boot.cfg
<uvos>
and leste config wont update it if it was touched
<sicelo>
I haven't. No reason to
<uvos>
maybe hildon-meta is not installed?
<uvos>
there was a packaginge problem where apt uninstalled it during upgrade some time ago
<uvos>
if so then charge-mode simply isent installed
<sicelo>
I think I have it (meta). Anyway, can't tell right now
rafael2k has joined #maemo-leste
<rafael2k>
I pulled the upstream changes of pine64-kernel to my fork
<rafael2k>
btw, how do you compile the kernel?
<Wizzup>
rafael2k: is that aimed at me?
<Wizzup>
rafael2k: what is 'upstream' here?
<Wizzup>
do you mean the maemo/beowulf-devel branch?
<rafael2k>
yes!
<Wizzup>
the kernel is built on the CI using git build package
<Wizzup>
if you want to mimic it locally then checkout the maemo-kernel-5.15 tag (or the maemo mobian-5.15 branch) and then run 'git checkout maemo/beowulf-devel debian' from it and then 'dpkg-buildpackage -b -uc'
<Wizzup>
(from memory)
<Wizzup>
I'm going to the supermarket for a bit
<sicelo>
Charge mode installed, softlevel=charge exists in boot.cfg
<sicelo>
Anyway, charging doesn't work at all for me now.
<uvos>
thats wrong
<uvos>
should be charge-mode or charge_mode
<uvos>
dont quite remember what i named it
<sicelo>
Anyone ever tested n900's IR with mainline? It probes perfectly well, and the proprties of the device can be fetched. Trying to send an IR pulse makes kernel hang instantly however
<uvos>
not me
<uvos>
but its just a gipo right? cant be so hard to fix it
<sicelo>
I'll maybe test it further in the near future but if someone has, would be nice to hear
System_Error has joined #maemo-leste
akossh has joined #maemo-leste
<freemangordon>
uvos: obviously both me and sicelo are facing exactly the same behaviour
<freemangordon>
I think it makes sense to revert that patch (or those patches) as of now, to be able to push -devel to -stable after some quarantine period
<Wizzup>
we can do that, but if we can find a fix that works too
<freemangordon>
I proposed one that will fix the behaviour to the state before patch, but uvos didn;t like it
<Wizzup>
I thought he had a fix
<freemangordon>
I don;t hink it is a proper one
<Wizzup>
but I didn't follow along
<freemangordon>
please read the backscroll, maybe I didn't understand it
<freemangordon>
brb
<Wizzup>
freemangordon: around 16:57 your time
<freemangordon>
mhm
<freemangordon>
but, this is a change in the behaviour
<freemangordon>
which needs testing as well. that's why I think it is better to revert, push to -stable and then try to fix whatever needs to be fixed
<Wizzup>
sure we can do that
<Wizzup>
it did make charging much more stable for me though, but we see it is better in some ways only
<freemangordon>
I am not saying the patch is bad or not needed, it is just that it needs more polishing
<freemangordon>
I prefer to be done after -stable release
<uvos>
the issue is independant of the patch really
<uvos>
anyhow just having the state report what target current fixes all reall issues
<uvos>
and thats a small easy one liner
<uvos>
we can talk about polling
<uvos>
or finding an irq later
<freemangordon>
the patch I proposed makes more sense to me, as it restores the behaviour as it has been before the ramp-up patch
<uvos>
but it dosent solve the issue
<freemangordon>
sure, but it is *another* issue
<uvos>
just because in your setup the electrical timeing hapens to line up like that
<uvos>
means nothing really
<uvos>
no its the same issue
<uvos>
just my patch alters timeing a bit
<uvos>
so this starts happening to you
<freemangordon>
uvos: just because it works for you means nothing, really
<uvos>
and sicleo too
<uvos>
if i change it to report target current
<uvos>
it will work for everbody
<uvos>
no matter what iductivity/regulation charecaristicts the usb wall wart hast
<freemangordon>
and it will report the real state incorrectly
<uvos>
*has
<uvos>
sure but we can investigate how to fix that latter
<uvos>
this patch exits because charging dident work for ME
<freemangordon>
current reporting is correct
<freemangordon>
*currently
<uvos>
except with one signle usb cable i have
<uvos>
well tough
<uvos>
we cant make it report correctly and not have the timeing issue
<uvos>
without polling
<freemangordon>
uvos: that's why I proposed to extend it to report the state after _avg has settlet
<freemangordon>
I know
<uvos>
or figureing more out about the chip
<freemangordon>
agree
<uvos>
so lets just fake it untill we know how to fix it for real
<freemangordon>
why? instead of delaying the initial state reporting for 100ms?
<freemangordon>
you may as well hardcode
<uvos>
thats terrible
<uvos>
sorry
<uvos>
it dosent solve the issue at all
<freemangordon>
I am not saying my proposal fixed the issue
<uvos>
just makes it maybe slightly less common
<freemangordon>
it will just make it like before ramp-up patch
<uvos>
right and it dident work before the ram up patch
<uvos>
just on different configurations
<freemangordon>
right, I am not saying to revert ramp-up patch, but to extend it
<uvos>
can you just let me fix my own damn patch
<uvos>
yeez
<freemangordon>
sure, after a -stable release
<Wizzup>
we do not need a -stable right now, I was just asking
<Wizzup>
if there is a fix that makes it work for us all we can wait a bit
<Wizzup>
no rush
<freemangordon>
and what about "charge-mode"?
<uvos>
what about it
<freemangordon>
it doesn;t work here either
<freemangordon>
and I didn;t play woth boot.cfg or whatever
<freemangordon>
*with
<uvos>
probubly one and the same issue
<Wizzup>
yeah I think so
<Wizzup>
it works for me
<uvos>
i dont quite remember how i had charge-mode detect if the device is charging
<Wizzup>
(charge mode)
<uvos>
but maybe i used status
<freemangordon>
maybe the same issue, yeah
<Wizzup>
but I ended up on the right side of this patch :)
<Wizzup>
it sounds like sicelo can maybe help test a new patch as well
<Wizzup>
uvos: so what do you think, should I exclude those charging patches from a new kernel build and then look at moving it all to stable, and then include those patches with a fix? I am not in a rush, just trying to get a sense what would work best for you :-)
<freemangordon>
tmlind: I am sure I checked that extension is not announced, lemme see what's going on
<tmlind>
freemangordon: ok
<tmlind>
trying to figure out why my es2gears_wayland stopped working..
<tmlind>
i think that happened already a while back, need to grep the irc.txt
<freemangordon>
uh: the check if for dri2_dpy->image->base.version >= 8
<freemangordon>
*is for
<inky>
uvos, i maybe forgot what was the problem with the keyboard, i remember i generated u a header file, but
<inky>
do we need it?
<inky>
if the maemo user chooses
<inky>
a, yes we needed that
<inky>
but the other problem now is that
<inky>
you don't know which language is being typed to execute setxkbmap
<inky>
but we know!
<inky>
because if i choose armenian layout then as i have chosen it
<inky>
setxkbmap am
<inky>
should be issued
<inky>
by vkbd
<inky>
otherwise i do two things
<inky>
i choose armenian, then in terminal type setxkbmap am
<freemangordon>
tmlind: yeah, my bad
<inky>
it can be done automaticlly
<freemangordon>
this has to be 8, not 14
<inky>
uvos, do you want we to give u a table of setxkbmap layouts that correspond to languages we hve in vkbd?
<freemangordon>
hmm, 8 should support modifiers too
<freemangordon>
tmlind: so, according to mesa, if you support EXT_image_dma_buf_import you must support EXT_image_dma_buf_import_modifiers too
<freemangordon>
tmlind: or, shall I build on the device?
<Wizzup>
inky: just wondering, does the h-i-m method of changing keymaps work for you
<Wizzup>
I don't think I got it to switch languages
<tmlind>
freemangordon: ok i'll try just a few mins
<freemangordon>
thanks!
<tmlind>
only 11 files to build..
<tmlind>
well 11 steps actually with linking
<freemangordon>
well, thats great
<tmlind>
freemangordon: yup, changing it to 8 fixes the issue
<freemangordon>
:)
<tmlind>
oh looks like install did not happen
<tmlind>
ERROR: Build directory has been generated with Meson version 0.60.2, which is incompatible with the current version 0.61.0.
<tmlind>
heh let's see if it will be a full rebuild :)
<tmlind>
phew only 38 steps, not a full rebuild after meson --reconfigure build
<_inky>
Wizzup: you mean with hildon programs?
<_inky>
or with X programs?
<uvos>
_inky: i yeah i know this is still a problem
<uvos>
_inky: its not a priority for me atm, sorry
<uvos>
_inky: so i dont want a table
<_inky>
uvos, i think we even know the names of the mappings.
<_inky>
yes, okay.
<_inky>
i mean the source code already contains the names.
<uvos>
_inky: i think it would be better if the vkb could just pick a couple of safe keycodes to overwrite
<uvos>
_inky: and then change the keymap on the fly
<_inky>
i mean, no need to take keycodes even
<uvos>
by modifing it with the keys it needs to send the string
<uvos>
and then restoring the keyboard map
<_inky>
i choose the layout explicitly
<_inky>
to type
<tmlind>
freemangordon: still getting wlroots error [wlr] [render/egl.c:765] Failed to query number of dmabuf formats
<uvos>
sure but the hwkybd also needs to wrok at the same time
<_inky>
it is in the source as hy_AM - then setxkbmap am should be executed.
<uvos>
so the way to make that happen is take the string the user wants the vkb to send to the applicaiton "abced"
<_inky>
if i choose russian, then it's ru_RU in our source, then setxkbmap will cover all the chars.
<uvos>
add abced to the keymap
<uvos>
send string
<uvos>
restore keymap
<freemangordon>
tmlind: ok, I think this is a bug in mesa then
<_inky>
i just had the idea that it could be much much easier.
<_inky>
because the user explicitly chooses the layout before typing
<uvos>
yeah but ru_RU dosent cover all the chars
<uvos>
is the problem
<_inky>
i choose the layout, then we know which setxkbmap needs to be executed
<uvos>
not even en_US covers all the chars
<uvos>
on droid 4 with english vkb and english hwkbd
<uvos>
becaus vkb has lots of spcial chars
<freemangordon>
tmlind: I will need some more time to see what can be done
<_inky>
what kind of chars, i don't know about it.
<uvos>
some on the second page
<_inky>
Wizzup: yes, with maemo apps maemo kbd works without forcing me to do setxkbmap manually.
<uvos>
like the pound symbol i think
<uvos>
some others
<_inky>
but with regular debian apps not.
<freemangordon>
tmlind: maybe it is a good idea to ask someone that knows more then me though
<tmlind>
freemangordon: it checks for >= 8 :) i'll try 7
<_inky>
i think it is much better for user now if the vkbd just execute setxkbmap according to the current layout, and the pound symbol not work, than scare the user away by telling them to execute setxkbmap each time.
<uvos>
and ru vkb with ru_RU keymap on droid 4 is entriely hopeless ofc
<freemangordon>
yeah, but then there will be no EXT_image_dma_buf_import as well
<_inky>
why hopeless?
<tmlind>
freemangordon: ah
<uvos>
becasue of all of the wrongly mapped keys
<_inky>
you mean hw kbd? i am very concerted with vkbd
<_inky>
also i don't have hwkbd on pinephone.
<uvos>
sure but you cant break the hwkbd to make the vkb work :P
<_inky>
eh.
<uvos>
anyhow as stated there is a solution
<uvos>
you have to have him modify the keymap on the fly
<uvos>
but its not a priority for me atm, sorry
<uvos>
maybe some one else wants to pick it up
<uvos>
Wizzup: just wait, ill give you a temp fix tomorow
<uvos>
and then we can discuss a proper fix at some later point
<freemangordon>
tmlind: how exactly does it fail?
<freemangordon>
because IIRC it was segfaulting before, no?
<freemangordon>
ah, "Failed to query number of dmabuf formats"
<freemangordon>
but, it should check for the extension first
<freemangordon>
tmlind: see dri2_query_dma_buf_formats
mepy has quit [Remote host closed the connection]
<freemangordon>
hmm, well, I think this is really bug in mesa
<tmlind>
freemangordon: i think we can disable it in the pvr driver but i need to look at that stuff more
<freemangordon>
I'd rather will fix mesa to check for proper image version
<freemangordon>
there was a check for dri_image version >= 15
<freemangordon>
and we report 14 now (which is wrong, but still not 15)
<freemangordon>
"With this change, queryDmaBufModifiers always returns zero modifiers."
<freemangordon>
actually it does not, for some reason
<freemangordon>
but rather returns FALSE
<tmlind>
probably more quirk handling
<freemangordon>
yeah, the reason is that our version is < 15
<tmlind>
hmm so should it be 15 then?
<freemangordon>
no because we don;t support that
<freemangordon>
it is 'our' dri driver that shall implement that and return sane values
<freemangordon>
but that function is not implemented in the blob
<tmlind>
so let's add back that dropped snippet?
<freemangordon>
:)
<freemangordon>
no, because we use the same mesa on PP, for example
<freemangordon>
ah, you mean the version?
<tmlind>
right the version check
<freemangordon>
yeah, maybe
<freemangordon>
but, I wonder if we shall raise an issue on mesa
<tmlind>
let me test adding the if (dri2_dpy->image->base.version >= 15... check back
<freemangordon>
ok
<freemangordon>
it seems they fixed only some of the code paths back then
<freemangordon>
tmlind: seems they fixed gallium dri2 frontend
<tmlind>
heh
<tmlind>
the version check for 15 was probably dropped for some old pc hardware
<freemangordon>
see dri2_query_dma_buf_modifiers in dri2 gallium frontend
<uvos>
well idk if upsream will be helpfull then
<uvos>
they just droped eveything except gallium 3d drivers
<freemangordon>
I think we shall patch egl_dri2.c to return zero modifiers instead of EGL_FALSE
<tmlind>
hehehe good luck merging that upstream :)
<freemangordon>
hmm? why?
<tmlind>
probably something somewhere breaks again
<tmlind>
but sure go for it if you have a proper fix in mind
<tmlind>
freemangordon: adding back the 15 check makes things work, but who knows what other things it might break..
<freemangordon>
hmm, wait, they say that 'formats' query shall be always suppoerted, no?
<tmlind>
sounds like they pulled back
<freemangordon>
"This allows users to use queryDmaBufFormats..."
<freemangordon>
ok, this is really a mess
<tmlind>
but we don't have the function implemented at all, it's null
<freemangordon>
yes, we don't
<freemangordon>
we don;t support that
<freemangordon>
I would say this is strictly against specs
<freemangordon>
but...
<freemangordon>
or, we can implement queryDmaBufFormats to return zero formats
<tmlind>
that won't help, see the wlroots links i pasted earlier
<tmlind>
we either need to implement them in a way that works, or just have !egl->exts.EXT_image_dma_buf_import_modifiers
<freemangordon>
yeah
<freemangordon>
well, I think moving the version check back is ok
<freemangordon>
either ways we carry our own patches
<tmlind>
yeah ok let me type up some kind of description
<tmlind>
seems to implement these functions we should just return two formats DRM_FORMAT_ARGB8888 and DRM_FORMAT_XRGB8888 looking at the wlroots fallback handling
<tmlind>
the pvr mesa hacks have some comments about pvr having multiple compatible options where some cannot be shown
<tmlind>
maybe we don't even need to call the blobs to implement this, but that can be always done later
<freemangordon>
I think version check is ok
<tmlind>
yup
<freemangordon>
that way wlroots will fallback
<freemangordon>
to those 2 formats
<freemangordon>
I will make a proper patch (along with version fix) afte I am back from holidays (sunday, most-probably)
<freemangordon>
unless someone beats me to it
<freemangordon>
I still thinks it make sense to open an issue on mesa bugtracker
<freemangordon>
tmlind: still, I think it will be good if we have chromeos pvr_dri_support to feed IDA with, to see what they do there
<tmlind>
sure, no docs
Boshtannik has joined #maemo-leste
<Boshtannik>
Hi to all!
<Boshtannik>
How can I be notified about keyboard mapping unmatching to be fixed?
_inky has quit [Ping timeout: 256 seconds]
inky has quit [Ping timeout: 240 seconds]
<tmlind>
hi, sounds like you need to set up a user account at github and subscribe for notifications
<tmlind>
freemangordon: probably the old modifiers code did not work as things have changed around, see c8a0660ab4d1 ("etnaviv: advertise supported dmabuf modifiers")
<tmlind>
seems like pscreen->query_dmabuf_modifiers needs to be implemented as the patch removing 15 version check adds checks for those
<freemangordon>
but this is for gallium, no?
<freemangordon>
not for egl
<tmlind>
argh you're right
<Boshtannik>
Ahh github? But it was microsoft ed..
<sicelo>
or manually visit the page at regular intervals, without an account. you can choose your poison ;-)
<freemangordon>
tmlind: hmm, see g_asFormats in pvrutil.c
<freemangordon>
but yeah, it is about dma_buf
<freemangordon>
anyway, I will stop for today
<tmlind>
freemangordon: yeah and note how we now have .bQueryDmaBufFormatsExclude unused
<freemangordon>
night!
<tmlind>
night, me out of here too
<Boshtannik>
Have built python 3.10 on my n900)
<freemangordon>
tmlind: yeah, maybe I shaved too much code, will see what can be done
inky has joined #maemo-leste
_inky has joined #maemo-leste
Boshtannik has quit [Ping timeout: 256 seconds]
<freemangordon>
uvos: BTW, I think it makes sense to not disable the second core while charging
System_Error has quit [Ping timeout: 276 seconds]
xmn has joined #maemo-leste
System_Error has joined #maemo-leste
<uvos>
freemangordon: sure yeah
<uvos>
freemangordon: did you see the config option?