akossh has quit [Quit: Leaving.]
diejuse has quit [Quit: Client closed]
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
fab_ has quit [Quit: fab_]
akossh has joined #maemo-leste
brosame has joined #maemo-leste
mdz has joined #maemo-leste
humanbeta has joined #maemo-leste
<humanbeta> I tested Motorola Altrix Lapdock with Pinephone Keyboard..it works..have to push two times button of PP Keyboard and write: xrandr --output HDMI-1 --mode 1366x768
humanbeta has quit [Quit: Client closed]
humanbeta has joined #maemo-leste
<humanbeta> needs quite many adapters to get connected.
<humanbeta> brightness controls and volume controls (inverted) works.
<Wizzup> cool
<Wizzup> arno11: cmt_pulse starting later, is that because otherwise pulse is not ready yet, or?
arno11 has joined #maemo-leste
<arno11> Wizzup: hi, nope cmt_pulse works fine excepting the alerting tone
<humanbeta> here is command needed to touchpad scrolling screen to see all pixels from right side of PP with Motorola Altrix: xrandr --fb 1440x768 --output HDMI-1 --mode 1366x768 --panning 1440x0
<arno11> Wizzup: starting cmt_pulse a bit later makes things working fine (like starting cmt_pulse from the user session)
<humanbeta> *Motorola Altrix Lapdock
<arno11> now we just need to find a clean way to set RT prio for PA and sphone (cmt_pulse doesn't need any particular prio now)
<Wizzup> arno11: what I mean is that it doesn't work when started earlier?
<Wizzup> arno11: also, does sphone really need RT? not just PA?
uvos__ has joined #maemo-leste
<uvos__> sphone in a call dose exactly nothing, it sits in select
<Wizzup> yeah
<uvos__> rt prevent sphone from being swapped out
<uvos__> swapped out sphone might be a problem when a call comes in
<uvos__> and when you want to stop a call in extream circumstances
<uvos__> but this is better solved by a cgroup
<uvos__> that mlocks
<arno11> Wizzup: as i said it works fine if it starts earlier
<Wizzup> arno11: ah ok, because your last commit makes it start later
<arno11> yes ofc, to make the alerting tone working again
<Wizzup> uvos__: I see
<Wizzup> arno11: ok
<arno11> for sphone, i really don't know
<Wizzup> it might be the swap thing
ceene has quit [Ping timeout: 260 seconds]
<arno11> yes indeed
<uvos__> Wizzup: oh btw, your sphone.ini.d file for sphone
<uvos__> i dont like that i lacks a number prefix, sphone sorts the files based natsort haveing a name like 50-* makes it obvious what overrides what
<Wizzup> ok, easy fix
<uvos__> yeah just mentioning
<Wizzup> re droid3
<Wizzup> I don't know what to do next other than analyse the regs and make an empty dts, but I will probably go back to tp first since I feel I'm not effective in this area
<uvos__> Wizzup: ok
<uvos__> ill diff the cpcap regs soon
humanbeta has quit [Quit: Client closed]
<uvos__> looking for sutch issues is never very effective
<uvos__> lots of blind poking around with a stick
<uvos__> i want jtag :(
<Wizzup> yeah, but I also forgot what we did like in 2020 or 2021 wrt sgx so that doesn't help either :p
<Wizzup> ok @ regs, I will keep the devices close by so I can do/run other stuff as needed
ceene has joined #maemo-leste
<arno11> Wizzup: ah, looking @my notes, sphone rt prio was a workaround when N900 was using 24bpp...because most of the time sphone window was too slow to appear during an incoming call.
<arno11> now it seems fine with stock freq and 16bpp (and no sphone rt prio)
<arno11> so we just need to focus on PA
<arno11> btw giving high rt prio to PA makes yt-dlp working amazingly well to stream videos on n900
<arno11> the trick is to get the real google video link through yt-dlp with --get-url option (it takes around 20sec) and then start the stream from smplayer.
<arno11> it works with live streaming as well (if 240-360p is available ofc)
<Wizzup> we shouldn't need too many of these rt tricks, maybe we should figure out what it really does for you
<arno11> there is just one trick now: PA
<arno11> and that's not really a trick with a low power device imo
<Wizzup> I understand, we need to up PA scheulding prio
<Wizzup> oh, ok, I misread what you wrote earlier
<arno11> :) no probs
<Wizzup> doesn't pa have a realtime flag/option?
<Wizzup> realtime-scheduling in daemon.conf?
<Wizzup> or, how do you set ti?
<Wizzup> it*
<arno11> the rt flag in daemon.conf doesn't work
<arno11> only chrt works without rt kernel iirc
<Wizzup> ok
<arno11> bbl
arno11 has left #maemo-leste [#maemo-leste]
brosame has quit [Ping timeout: 240 seconds]
<uvos__> cgroups would work
<uvos__> idk how to manage cgroups without the advantage of systemd however
<Wizzup> openrc can do cgroups for sure
<uvos__> a rt and a mlock cgroup would be great
<uvos__> Wizzup: sure but openrc dosent start processies in user contexts
<uvos__> Wizzup: systemd-user is another full systemd for eatch session that allows one to do these kinds of things properly
<Wizzup> isn't pa still started through /etc/init.d ?
<uvos__> pa sure
<uvos__> but the stuff we want to mlock no
<uvos__> actually pa no
<uvos__> we switched to session pa a while back
<Wizzup> it looks like with cgclassify one can move processes to a cgroup
<Wizzup> or through procfs or so
<uvos__> i gues we have to add this to dsme, which itself is really just a hack around not having a real session level init itself anyhow
<Wizzup> more than anything it just predates a lot of this stuff :)
<uvos__> but then it wont work for dbus activation
<uvos__> hmm
<freemangordon> dsme already moves processes it starts to elogind session if one exists (and is defined through env var)
<freemangordon> moving process to elogind session is basically assigning it to a cgroup
<freemangordon> so at least XSession dsme started processes already belong to /sys/fs/cgroup/elogind/c1/
<freemangordon> uvos__: but, my cgroups-fu is not good enough so I have no idea what will happen if we create subdir of c1 dir with mlock and whatever cgroups settings we want for some pids
<uvos__> freemangordon: thatl work but not for processies dsme dosent start directly like dbus activates ones
<Wizzup> from a practical pov, do we need to mlock some of the dbus activated ones?
<freemangordon> do we care? I mean - do you have a particular process in mind that woudl suffer from that issue?
<freemangordon> Wizzup: exactly
<freemangordon> uvos__: we can always pre-start dbus process
<freemangordon> if we want it mlocked or something
<freemangordon> uvos__: on fremantle, those thing are done by ohm
<freemangordon> so, we can choose to have ohm in leste as well
<uvos__> i gues, but n900 would probubly be thankfull if not everyhing where started on boot directly since it gets hit pretty roughly on boot
<freemangordon> right, but thats another story, like, we shall reconsider what needs to be started in xsession.d and what in xsession.post
<freemangordon> assigning pids to cgroup is orthogonal to that, no?
<freemangordon> also, I think elogind supports some kind of "process started" agent
<freemangordon> so we may hook on that
<uvos__> no idea, maybe
<freemangordon> still, what will happen if we move a pid from c1 to a subdir, do you know?
<freemangordon> or, it has to be in both dirs?
<freemangordon> I don;t really have details on how cgroups work in that regard
<uvos__> im pretty fuzzy on this since systemd deals with the details with this on other systems
<uvos__> but i seam to remember the hierachy gettig removed in cgroups2
<uvos__> so that may be legacy in the first place
<uvos__> but i would have to look it up
<freemangordon> please do what you have some spare time
<freemangordon> *when you*
<freemangordon> as without those details we won;t be able to fix it properly
<freemangordon> I'll experiment a bit on leste as well in the meanwhile
<uvos__> check
<freemangordon> hmm, we cannot mlock through cgroups
<freemangordon> we can only set swappiness to 0
<freemangordon> I have to check what ohm does on fremantle
<uvos__> cgroups has unevictable which is mlock
<uvos__> besides some difference in behavirou around non-anynomes mmaps
pere has quit [Ping timeout: 246 seconds]
brosame has joined #maemo-leste
diejuse has joined #maemo-leste
diejuse has quit [Ping timeout: 240 seconds]
diejuse has joined #maemo-leste
uvos__ has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
Wizzup has quit [Ping timeout: 264 seconds]
Wizzup has joined #maemo-leste
mrkrisprolls has quit [Ping timeout: 246 seconds]
diejuse has quit [Remote host closed the connection]
diejuse has joined #maemo-leste
<diejuse> testing testing
<Wizzup> works
<diejuse> perfect. It illll
<diejuse> From Maemo Leste, proot, Z Flip5, Pidgin app
<diejuse> and okuda theme hehe
arno11 has joined #maemo-leste
<arno11> diejuse: Leste proot on Z Flip5 ? amazing !!!
<diejuse> yes!
<freemangordon> video or didn't happen :p
<bencoh> using halium ?
<diejuse> I will make and upload a video when all problems are solved. osso apps not working for example
<bencoh> which makes me think ... maybe I should try using proot for the crossbuilder instead of lxc
<bencoh> it might be simpler for everyone
<freemangordon> I guess maemo-launcher is not started
<bencoh> diejuse: how does the graphic stack work with proot on android?
<diejuse> i am shopping. latter I will tell
diejuse has quit [Remote host closed the connection]
<bencoh> :)
sch has quit [Ping timeout: 264 seconds]
ceene has quit [Ping timeout: 268 seconds]
arno11 has left #maemo-leste [#maemo-leste]
mrkrisprolls has joined #maemo-leste
xmn has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
mdz1 has joined #maemo-leste
mdz has quit [Read error: Connection reset by peer]
mdz1 is now known as mdz
pere has joined #maemo-leste
hexagonwin has joined #maemo-leste
arno11 has joined #maemo-leste
diejuse has joined #maemo-leste
<diejuse> bencoh When I chrooted Maemo with my Unihertz Titan smartphone I used XSDL Xserver app as X Window System / X11 server for Android. Now I am using Termux-X11 which works better. It is more efficient and uses less battery.
<diejuse> battery power
diejuse96 has joined #maemo-leste
<diejuse96> freemangordon The problem is "/etc/init.d/dbus start". I get  "[FAIL] dbus is not running ... failed!".  And errors like "Failed to connect to socket /tmp-dbus-xxxxxxx: No such file or directory" from hildon-home, hildon-desktop and hildon-input-method
diejuse has quit [Ping timeout: 250 seconds]
<diejuse96> But that happens on my Z Flip5 (Android 14) and Surface Duo (Android 12) but not on older phones like Blackberry Key 1 (Android 7) and ZTE Axon M (Android 7). Apparently the higher the version of Android, the more secure it is and the more difficult it is to root and mount directories such as /proc and /sys.
uvos__ has quit [Remote host closed the connection]
<diejuse96> The fact is that on the most modern mobile phones I cannot see the time in the status bar, nor open other apps such as X terminal, Setting, Clock, PDF reader, App manager. But I can use LXTerminal, Abiword, Thunar... The main screen backgrounds and window management work well.
<freemangordon> diejuse96: without session bus...
<freemangordon> why would dbus not start?
<diejuse96> I'm investigating but I don't know. It throws an error message: "/etc/init.d/dbus: 50: [: -lt: unexpected operator" and then "[ok] Starting system message bus: dbus" but it is not real because with "/etc/init .d/dbus status" get FAIL.
<freemangordon> ah, startup script fails
<freemangordon> hmm, /etc/init.d/dbus is not provided by us, it is dbus package that provides it, afaik
<freemangordon> yeah, that's upstream provided
<freemangordon> seems shell interpreter is buggy or something
<diejuse96> In any case, I modified the shebang of the script to bash and adapted line 50, ensuring that there were no errors. But it still doesn't work. Therefore I think the script is not the problem. As I said before, on my older phones with Android 7 there is no problem with the script.
<freemangordon> dif you try to run dbus by hane, to see if it starts?
<freemangordon> *hand
<freemangordon> I mean dbus the binary
<diejuse96> The truth is that I don't know what the problem is. Well, in summary, I think the problem is proot with Android 14 is more difficult for security reasons than with Android 7.
<freemangordon> I see
<freemangordon> well, I can;t help here, my android knowledge is close to zero
<diejuse96> What is your daily use smartphone? I'm curious,
<Wizzup> nokia n900 ;)
diejuse96 has quit [Ping timeout: 250 seconds]
diejuse has joined #maemo-leste
<diejuse> The best. It is the phone that I remember best and that is why I try to emulate its system on modern cell phones. Unfortunately the battery had a very short life.
<diejuse> *has
<diejuse> What steps do I do for vertical rotation?
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup> diejuse: xrandr might be enough
<Wizzup> but there is also a dbus message to change rotation
<Wizzup> or a signal, rather
<diejuse> I understand. Is it possible to open an application like osso-xterm without using dbus, how can I do it with xfce4-terminal?
<Wizzup> I am not sure if I fully understand the question
<diejuse> I mean that, using Maemo proot on modern Android smartphones, I can open Debian applications but not Maemo's own applications such as osso-xterm, Settings, Clock, PDF Reader...
<diejuse> The reason is that with Maemo's own applications I get the error "Could not connect to System D-Bus. Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory". I don't have that error when I open Debian applications.
<Wizzup> right, mameo-launcher might not be running
<Wizzup> or at least applications can't talk to it over dbus
<Wizzup> that is definitely worth fixing
<diejuse> I'm going to record a short video to understand each other better.
<Wizzup> okay :)
<Wizzup> diejuse: so many maemo applications 'spawn' by sending a dbus message to maemo-launcher telling it 'start this program'
<Wizzup> or rather, the programs themselves are a 'symlink' to the maemo-invoker (or so) program, which from argv[0] will figure out what to spawn
RedW has quit [Remote host closed the connection]
<diejuse> Hmm. Is there any workaround so they can start without sending the dbus message?
RedW has joined #maemo-leste
<diejuse> Like Debian apps?
<Wizzup> not without recompiling, but you'll really want dbus to work for maemo to function properly
<Wizzup> is it not possible to run dbus in proot?
<diejuse> It would be the best but I think I won't be able to do it because it doesn't seem possible in recent versions of Android.
<Wizzup> hmm... how so?
<Wizzup> is this because of the buggy script?
<diejuse> However, I can start Devuan with another dbus. I'm confused.
<diejuse> Because I tried installing Devuan via proot and it works! That's why I'm confused.
<diejuse> I don't know if the script is the culprit.
<diejuse> I mean "dbus-launch –exit-with-session startxfce4" works
<diejuse> on Devuan
<diejuse> But ""/etc/init .d/dbus start" no works