Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
buZz has quit [Ping timeout: 244 seconds]
buZz has joined #maemo-leste
buZz is now known as Guest5968
Guest5968 is now known as buZz
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
auanta has quit [Quit: leaving]
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 252 seconds]
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
Daaanct12 has quit [Ping timeout: 268 seconds]
macros_ has quit [Ping timeout: 255 seconds]
Daaanct12 has joined #maemo-leste
macros_ has joined #maemo-leste
Daaanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #maemo-leste
BlagovestPetrov[ has quit [*.net *.split]
BlagovestPetrov[ has joined #maemo-leste
mardy has joined #maemo-leste
Oksanaa has quit [*.net *.split]
Daaanct12 has quit [Remote host closed the connection]
Oksanaa has joined #maemo-leste
Daanct12 has joined #maemo-leste
<freemangordon>
tmlind_: we still have that 'dma modifiers' or whatever issue in mesa, right? I am going to fix it, but could you provide a simple test-case I can use on leste?
Pali has joined #maemo-leste
<tmlind_>
freemangordon: ah right, the test case i used was trying to start current version of sway with just the pending sway patch applied
<tmlind_>
freemangordon: have not updated wlroots and sway git trees for several months, presumably you just need the commit above still and can just use current git versions of wlroots and sway
Pali has quit [Ping timeout: 256 seconds]
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
dev has left #maemo-leste [Disconnected: closed]
xmn has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
<freemangordon>
tmlind_: so, I have to build something? will it build on leste?
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 268 seconds]
joerg has quit [Quit: this shouldn't have happened... ever]
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 256 seconds]
<tmlind_>
freemangordon: should build just fine on leste, not sure what dependencies it might bring in though
<tmlind_>
freemangordon: wlroots tinywl test app might be enough to test it with no sway needed
<tmlind_>
i'd assume similar checks will eventually propagate further as the wlroots folks are also patching mesa
<tmlind_>
so hopefull will help a bit also making m-l a bit more future proof :)
<kabouik>
Wizzup: https://0x0.st/o2UH.png It's already reserved, I'm sorry I couldn't reach IRC in the last days, I was away. I assume you would be more interested in a Pro1 anyway, and hopefully some Pro1x owners will sell their Pro1
Pali has joined #maemo-leste
auanta has joined #maemo-leste
_uvos_ has joined #maemo-leste
<Wizzup>
kabouik: check, ty anyway
<_uvos_>
fremangordon: i dont like your tone, and we disscused this behavior before. its works this way because the only piece of information about the boot is if charging/usb is enbaled/plugged whenuserspace starts, we dont have anything more because the stock kernel swallows it so this is the best we can do (enter charge mode when ever the battery is charging on boot)
<Wizzup>
freemangordon: btw: I might have a pretty reliable way to crash X on d4
<_uvos_>
now certenly you could have kexecboot relay the boot reason information to the mainline kernel
<_uvos_>
but we would still need this behavior as a fallback because ever phones bootloader has its own special way to give the kernel this information
<_uvos_>
popular is for example appending random strings to cmdline
<_uvos_>
so we would need code for every device ergo we need a fallback where we dont
<_uvos_>
regaring entering charge mode at 99% @buzz
<_uvos_>
this is because the d4 kernel is not so great
<_uvos_>
and almost never flags the battery as fully charged
<buZz>
hmhm, but, it can see (in the animation) that its >30% , right?
<_uvos_>
it would not enter charge mode otherwise
<buZz>
so maybe just skip the 'stay here' when >x% ?
<buZz>
not just at 'fully'
<_uvos_>
when its booted via usb plug it should stay
<buZz>
why?
<_uvos_>
untill full and then shut off
<buZz>
shut off? :O
<_uvos_>
which is what it dose
<_uvos_>
d4 kernel bugs aside
<buZz>
i'm not sure why anyone would want that?
<buZz>
whats the usecase? why would a person want to wait till battery is 100% until continueing boot?
<_uvos_>
it dosent continue
<_uvos_>
it shuts down
<_uvos_>
the usecase is i want to charge the phone while "off"
<buZz>
O_o
<_uvos_>
so it charges fully and then exits charge mode
<_uvos_>
to off
<_uvos_>
this is how charge mode works on ever device i have ever used
<buZz>
-afaics- 'charge mode' desire on d4 came mostly because of the 'we cant finish boot with just x % battery'
<buZz>
so when we're (well) above that x% , we could just continue boot?
<_uvos_>
no charge mode exits because its usefull
<_uvos_>
it allows charging whout the device being on
<_uvos_>
the fact that the kernel is running is an implementation detail
<buZz>
i still dont really see a usecase
<_uvos_>
weill every phone manufacture ever dose
<_uvos_>
and i do to
<buZz>
yeah? whats the usecase then?
<_uvos_>
i just told you
<buZz>
your phone is off & empty, you hook it up to power, and then come back to a phone thats off?
<buZz>
'but full' :D
<_uvos_>
yes if i dident turn it on
<_uvos_>
i dont want it on
<buZz>
it pretty much sounds like 'i wanna charge but not use' is not such a normal usecase
<_uvos_>
maybe for you
<_uvos_>
and thats fine
<_uvos_>
this is configureable via text file bte
<buZz>
so a user has 1 device, wants to be online with the 1 device , it cannot boot because its too empty
<_uvos_>
btw
<buZz>
should that user now wait 2-3 hrs before its 100%?
<buZz>
ah, cool, i didnt know
<_uvos_>
then he shal charge it a bit in charge mode
<_uvos_>
and then turn it on
<_uvos_>
by pressing power
<_uvos_>
charge mode prevents exit when its unsafe
<_uvos_>
ie to low
<buZz>
right, so it could just continue when safe?
<_uvos_>
it could, but the point is the device should not turn on unless the power button is exercised
<auanta>
idk..if you wanted to turn it on to use it you could...press the power button? it'd be kinda annoying to have it turn on upon plugin..i'd have to shut it down.. but don't mind me..
<_uvos_>
exactly
<buZz>
auanta: with 'charge-mode' you have to 'power it on' with plugging a USB cable, it will 'fully boot' , then hit the SDL tool
<_uvos_>
it hardly fully boots
<buZz>
i dont really see a config file for it? hmm
<buZz>
_uvos_: within 1minute after that charge-mode , and then pressing power button, you're in hildon
<buZz>
i'm pretty blond, guess i'm really not seeing it
<_uvos_>
you can have the script do whatever you want
<_uvos_>
depending on exit reason
<_uvos_>
of the binary
<buZz>
ah, the textfile for config is the .sh ?
<buZz>
right , ok :)
<buZz>
still think a >x % charge 'continue with boot' would not be very unwelcome :P
<buZz>
maybe i'll just mod that in and try
<auanta>
idk how you plan on making it but if it's touch screen activated, consider use case where i have e.g. a battery brick and the phone is in my pocket.. if you do that, you would need volume keys and power button to select i would imagine
_uvos_ has quit [Quit: _uvos_]
<buZz>
select what? atm its not touchscreen activated, just by 'is there a usb cable with power attached'
<auanta>
oh, the 'continue with boot' if that is going to be something that shows up while charging i wouldn't want it to accidentally get selected while in my pocket or something
<auanta>
but now i reread and see i didnt parse correctly
<auanta>
nvm
auanta has quit [Quit: Lost terminal]
<sicelo>
regarding charging-sdl, just need to clarify that it doesn't help charging in any way.
<_uvos_>
sicleo: upstream charing-sdl and our charging sdl has nothinin common
<_uvos_>
except some of the code that renders the battery
<_uvos_>
it works entirely different
<sicelo>
you're implying that ours helps battery charging?
<_uvos_>
that said yes it dosent help charging except that it turns off the backlight and termniates userspace bingup early
<sicelo>
ok
_uvos_ has quit [Client Quit]
Keeblo has joined #maemo-leste
Keeblo has quit [Remote host closed the connection]
vagag has joined #maemo-leste
Livio has quit [Ping timeout: 256 seconds]
<freemangordon>
uvos: while I agree that phone should not auto power on if a charger is plugged, it should not remain in charging mode after a reboot
<freemangordon>
also, what will happen if you have an alarm while in charge mode?
<freemangordon>
uvos: imagine - you are sleeping and your phone is on the charger where you left it just before you start sleeping. with almost empty battery. 15 minutes after you are asleep, the is a power outage for long enough so the battery gets fully depleted. eventually electricity is restored, but your phone stays in charging mode. Your morning alarms do not ring, you are late for work and you are sacked.
<Wizzup>
We can all imagine the scenario, but we're not at the point where we claim this reliably works anyway
<freemangordon>
ok, but then why implement "stay in charge mode forever" instad of just continuing boot when there is anough charge?
<freemangordon>
*enough
<freemangordon>
this brings more harm than good currently
<Wizzup>
it hasn't bothered me yet, but I suppose if you're debugging remotely it could be
<freemangordon>
to me, currently the only use case is: "see, we can do it"
<Wizzup>
the whole point of charge mode is to prevent boot loops
<freemangordon>
caused by?
<Wizzup>
lowbat
<freemangordon>
low battery?
<freemangordon>
sure, but this is not how it behaves
<freemangordon>
the only scenario in which phone shall stay in charge mode after there is enough battery charge is iff a charger is connected after user powered it down
<freemangordon>
in all other cases it shall continue
<freemangordon>
Wizzup: "I might have a pretty reliable way to crash X on d4..."
<freemangordon>
elaborate please
<freemangordon>
hmm, just seen the note about my tone...
<freemangordon>
uvos: sorry, I find nothing wrong with my tone
<freemangordon>
also, we may have discussed it back then, but charging mode was not working at all. back then.
<freemangordon>
yesterday it was the first time ever I saw that animated battery
<freemangordon>
and I was a bit of surprised when it was just sitting like that
<freemangordon>
so, despite my tone(whatever is wrong with it), this is broken UX. The fact that the current 'user' was me does not make it less broken
<freemangordon>
speaking of who likes what, I also don;t like the way you push *your* usecases to the others.
<freemangordon>
disregarding the other users comments/suggestions
<freemangordon>
tmlind: no way to build on leste:
<freemangordon>
meson.build:1:0: ERROR: Meson version is 0.56.1 but project requires >=0.58.1
<freemangordon>
anything else I can use?
<sicelo>
maybe that version is available in (devuan's equivalent of) backports?
<freemangordon>
I am already on backports
<freemangordon>
the one in leste is 0.46
<freemangordon>
sicelo: maybe I can install it with pip
<sicelo>
yeah sounds like an idea
<freemangordon>
ok, thise guys are crazy
<freemangordon>
*those
<freemangordon>
DEPRECATION: CMake support for versions <3.17 is deprecated since Meson 0.62.0.
<freemangordon>
Dependency wayland-server found: NO found 1.16.0 but need: '>=1.20'
<freemangordon>
I don;t see how I can compile that
<freemangordon>
does anyone know how to pass library directory to meson?
<freemangordon>
ok, figured it out (subprojects)
auanta has joined #maemo-leste
<auanta>
just to give a fair warning... i'm going in to edit the wiki for the PinePhone
<sicelo>
you're more than welcome. the wiki definitely needs some love
<auanta>
:)
<auanta>
does anyone know how to get maemo to boot on the emmc?
<auanta>
i'll test it and put it in the instructions. current instructions are lacking
<auanta>
the old instructions to modify mmcblk0 to point to mmcblk2 no longer work, and a simple dd to the emmc doesn't either. i will retry with a new partition table though..
<auanta>
(boot.txt no longer exists in the images)
<auanta>
i tried changing the fstab.. but actually it does point to mmcblk2 so maybe thats why :P
<tmlind>
freemangordon: ok great hopefully git subproject will help :)
dev has joined #maemo-leste
uvos__ has joined #maemo-leste
Twig has quit [Ping timeout: 268 seconds]
<freemangordon>
tmlind: it does, to the extent :)
<freemangordon>
tmlind: "WARNING: Subproject 'libdrm' did not override 'libdrm' dependency and no variable name specified"
<freemangordon>
"Dependency libdrm from subproject subprojects/libdrm found: NO"
<freemangordon>
tmlind: ok, I build that (in amd64 VM) using defaults, what am I supposed to run?
<freemangordon>
or, shall I enable some backen?
<freemangordon>
*backend
<auanta>
new partition table on the emmc, dd'd it on there.. i'll leave it on the charger and see if it boots. i think last time i did it on the microsd, it took a long time on first boot and thought it was dead. all the latest boot times have been much shorter.
<auanta>
perhaps there's some initial scripts that go or something
<sicelo>
that's strange, i think
<freemangordon>
sicelo: any idea what am I suposed to do with this wlroots tingie?
<sicelo>
you can start it from console (so stop h-d)
<freemangordon>
start what?
<freemangordon>
oh, wait
<freemangordon>
tinywl?
<sicelo>
sway :-)
<freemangordon>
where it is?
<sicelo>
oh yes, in your case tinywl
<freemangordon>
ok, it started under h-d
<freemangordon>
what it does?
<freemangordon>
I see a black screen :)
<sicelo>
:-P
<freemangordon>
so, what does this mean?
<freemangordon>
that I shall do the same on d4?
<freemangordon>
and see if it errors out?
<sicelo>
i think so
<freemangordon>
ok
<sicelo>
i'm not sure exactly what tmlind and yourself were testing but yes, something like that :-)
<freemangordon>
me neither :)
<sicelo>
i don't know if starting it under h-d won't skew results, but let's see
<freemangordon>
well, he tmlind said the error is related to missing gles extension support
<freemangordon>
so h-d should not interfere
<sicelo>
https://pastebin.com/yN9r386U for sway, i use this script. you can try using it with tinywl if it complains while starting
<sicelo>
ah, ok
vagag has left #maemo-leste [Error from remote client]
<freemangordon>
sicelo: any wl terminal emulator?
<sicelo>
foot os
<sicelo>
foot is a good one
<freemangordon>
ok, we are here:
<freemangordon>
00:00:00.424 [render/egl.c:766] Failed to query number of dmabuf format
<freemangordon>
I guess this is what tmlind is talking about
<freemangordon>
oh, no, another mesa build on d4 :D
<Wizzup>
hi
<Wizzup>
freemangordon: re: X crashing, osso-xterm increase/decreasing font size very often crashes it for me
<Wizzup>
freemangordon: today in the A1 shop when I was trying to receive a SMS and I had to reboot the phone and tell the guy to send the SMS again for example :P
<Wizzup>
auanta: great @ wiki
<freemangordon>
Wizzup: ok
<Wizzup>
freemangordon: I tried it earlier this afternoon and then it didn't crash, but usually when it crashes I'm doing exactly that (font size changes)
<buZz>
maybe the volume-fontsize can become a toggle in xterm's config?
<Wizzup>
buZz: do you mean that the volume buttons work in xterm?
<Wizzup>
in my case I was purposefully changing the fonts
<buZz>
Wizzup: atm volumebuttons change fontsize for me, or arent you talking about those fontsize changes?
<buZz>
ah, you werent :P
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<freemangordon>
Wizzup: how do you change it? from th esettings?
<Wizzup>
freemangordon: volume buttons
<Wizzup>
buZz: I was
<Wizzup>
freemangordon: yeah just broke it again
<Wizzup>
(X)
<buZz>
might be related to that xterm crash i had before?
<buZz>
i've only been seeing that since i enabled bitmap fonts
<Wizzup>
buZz: could be, it's known that we have some X crashes, but with this one it's relatively easy to reproduce
<buZz>
ah, it didnt crash X for me, just xterm
<buZz>
but repeatadly, until i deleted its settings
<Wizzup>
never saw that before
<buZz>
quite sure thats about the bitmapfonts, i still need/want to make a proper issue out of it on freemangordon's request
<Wizzup>
issues are cheap, go for it :D
<freemangordon>
Wizzup: ok, will have a look
<freemangordon>
but first will try to fix mesa, that should be easy
<Wizzup>
I think the virtual keyboard might be on by default
<Wizzup>
>Some rendering bugs in portrait mode remain, so the default desktop orientation is landscape for now (xrandr -o right). Please note that if orientation is changed (e.g. with xrandr -o normal) the ui will still be reading original key positions.
<Wizzup>
not sure about this one
<Wizzup>
>Screen brightness adjustments in UI do not work on the Pinephone yet. There is also a user reported when "brightness" UI setting is set to minimum (no visual change normally), the screen will stay black after reboot with WiFi set to ON with kill switch. However screen is normal after reboot if WiFi set to OFF with kill switch even minimum "brightness" UI setting. You may still change the screen
<Wizzup>
brightness with terminal commands: xrandr --output DSI-1 --brightness 0.5
<Wizzup>
this is solved, pretty sure
<auanta>
also update on the pinephone eMMC boot, yeah it didn't boot even after a new msdos partition table and dd'ing it to eMMC
<auanta>
i'll say it 'booted' but remains a black screen with a yellow light
<auanta>
something stopped it in the boot process
<auanta>
hmm is there a way i can see the output?
<auanta>
during bootup
<auanta>
waiting on the others before i edit the wiki to remove the things Wizzup mentioned