<samueldr>
note that under the VM DPI cannot be configured, so if the environment scales things according to DPI it won't look as expected
<dxb[m]>
not too sure what to do about the login screen right now... it's the standard lightdm login screen for nix but there's no keyboard, so i keep having to plug a keyboard into my phone to login lol
<dxb[m]>
it looks fine on my phone actually
<samueldr>
(I looked into it... and it looks like to fix it QEMU would need too much work for what I'm comfortabl with)
<samueldr>
I don't really know
<samueldr>
I assume that this needs to be looked at for every setup with lightdm
<dxb[m]>
this is mostly based on noneucat's packages and module, but i've updated it to work with the latest commits
<samueldr>
since even if it autologins (like the example demo system) a crash will go to the login screen
<samueldr>
which is not helpful
<dxb[m]>
yeah
<dxb[m]>
sxmo seems to have their own login screen... unless that's the pmOS login screen. i'm not sure
<dxb[m]>
but their keyboard is already up when it gets there
<samueldr>
is there an sxmo lockscreen?
<dxb[m]>
i actually haven't looked into it very much, maybe i should :p
<dxb[m]>
there's no lockscreen... but i heard they were working on one. i think someone has a PoC up
<dxb[m]>
and some weird quirks with the keyboard... mostly just that i can't use any of the modifiers like ctrl or shift
<dotlambda>
dxb: Did you use sxvkbd and clickclack from Nixpkgs?
<dotlambda>
*svkbd
<dxb[m]>
no, i'm using proycon's svkbd
<dxb[m]>
and i don't think i have clickclack
<dxb[m]>
that's just for feedback right?
<dxb[m]>
most of what i have is just noneucat's packages and module from his nur repo but i've updated it to use the latest builds of the sxmo stuff. but his svkbd package uses the old sxmo-svkbd instead of proycon's so i made a new package for that
<dxb[m]>
oh interesting lol. i listened to that but i didn't remember that part
<dotlambda>
If you make a pull request adding more sxmo packages to Nixpkgs, please ping me.
<dxb[m]>
the build script still pulls his own repo i believe
<dxb[m]>
the sxmo-build script
<dotlambda>
And starting July or something, I wanna create an examples/sxmo-demo for mobile-nixos.
<dotlambda>
It just does that because his mirror is hosted on srht, just like the other sxmo software
<dotlambda>
Same goes for his clickclack mirror
<dxb[m]>
oh i see
<dxb[m]>
i wasn't aware that there were any xsmo packages in nixpkgs. everything i'm using is just a fork of noneucat's nur-packages repo with my own changes to update stuff
<dxb[m]>
i see now that you have lisgd on nixpkgs...
<dxb[m]>
does it work?
<dxb[m]>
cause the one i'm using is not working
<dotlambda>
Tbh, I haven't tried it on the PinePhone.
<dotlambda>
But if the correct device is there, I see no reason for it not working.
<dotlambda>
What's the problem you're having with lisgd?
<dxb[m]>
isn't that what allows for the gestures?
<dxb[m]>
like swiping at the top for the backlight and on the side for volume, etc?
<dxb[m]>
gestures just aren't working at all
dev_mohe has joined #nixos-aarch64
<dxb[m]>
i'm not sure how to figure out which device it should use though...
<dxb[m]>
i'm also not sure where or if it's being started. i haven't gotten into that stuff yet
<dxb[m]>
i only have a very surface-level knowledge of most of this tbh lol
<dxb[m]>
sorry, i sent a description of what's in there but i guess it didn't send or something?
<dxb[m]>
anywho, /dev/input has event0 through event4 and a folder called by-path which has a punch of events starting with platform-
dev_mohe has joined #nixos-aarch64
<dotlambda>
Try /dev/input/event1 using lsgi.override { conf = "..."; }.
<dotlambda>
But I really don't know which one it is, can't check on my own phone right now.
dev_mohe has quit [Remote host closed the connection]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
raspi4 has joined #nixos-aarch64
<dxb[m]>
yeah, if that doesn't work i can just try them all lol
<dxb[m]>
can't i just call it with `-d /path/to/device`?
<dotlambda>
Yeah, that's way better for testing :)
zupo has joined #nixos-aarch64
<samueldr>
prefer a stable path found under /dev/input/by-*
<samueldr>
not sure which between id and path
<samueldr>
probably path, as it should be using the names of the physical interfaces it uses
<dotlambda>
We should introduce a mobile-nixos option to set the touchscreen's device. Could be useful in mutiple modules.
<samueldr>
hmm
<samueldr>
imo instead the software should sniff all input devices and react accordingly
<samueldr>
since you can know
<samueldr>
BUT
<dotlambda>
not something a suckless tool would do I guess
<samueldr>
as we can see, not all software does
<dotlambda>
but then again it's fair if you have to configure sxmo yourself
<gchristensen>
As a user on my mobile device, I want my software to be extremely ultra minimal, so that I need a compiler to use my mobile device.
<samueldr>
yeah, the idea isn't out of question, but let's see how far we can go without
<dotlambda>
guessing the device would be bloat
<samueldr>
gchristensen: exactly
<samueldr>
if we had such an option
<samueldr>
I'd prefer something like "deviceAliases"
<samueldr>
where we can set `/dev/input/by-path/xx-yy-zz -> /dev/input/touchscreen`
<samueldr>
so that we don't accumulate specific device alises
<samueldr>
aliases*
<dotlambda>
samueldr: that sounds good and should just be a NixOS option
<samueldr>
maybe it already is
<samueldr>
tmpfiles.d ?
<dotlambda>
yeah that should work
<samueldr>
though having a usage-specific interface on top of tmpfiles.d might be worthwhile too
<gchristensen>
+1 the current interface is imho terrible!
<andi->
isn't a ruby runtime already a compiler (framework)?
<gchristensen>
I am not sure what you just said :D
<andi->
samueldr: (not trolling) have you thought about devices with >1 touch screens? Weren't those happening a few years ago?
<samueldr>
andi-: that's why software should detect the hardware
<samueldr>
as for mapping the output to displays
<andi->
I was referring to the aliases.
<samueldr>
ah
<samueldr>
that's why I'm not all fond of them
<andi->
It isn't just "the touchscreen"
<samueldr>
and I said that software should detect it :)
<andi->
ok
<samueldr>
I'm having pragmatic thoughts here... if there's garbage software that needs to be hardcoded to a path, let's provide a "well-known" path for those
<dotlambda>
I don't know if different revisions of e.g. the PinePhone have a different path for the touchscreen. If so, this would be mostly useless.
<samueldr>
andi-: I think mruby can be used without the compiler part since it works with bytecode ;)
<andi->
but you can build a C compiler using ruby ;-)
<samueldr>
oh, yes, we probably should
<andi->
I still struggle with most basic ruby code... missing static types and verbose syntax... Very unlikely I'll chip in :P
<dotlambda>
So which touchscreen does the software choose if there are multiple? I guess it has to be configurable after all.
<samueldr>
depends on the software!
<samueldr>
my boot interface code would assume all of them are linked to the main display
<samueldr>
and it displays to the main display
<samueldr>
now, that's not good
<samueldr>
but allows you to start
<samueldr>
AFAIUI it's the "DE"'s job to deal with mapping the touch input to the right displays
<samueldr>
I don't know how they do it
<dotlambda>
Btw, has any work been done to make LUKS unlocking possible during mobile-nixos' boot process?
<samueldr>
if you want to see an example configuration
<samueldr>
DO NOT use a nix build to produce a pre-encrypted disk unless you know what it means security wise
<samueldr>
this is an open question that will be solved once I start solving the "installer" question
<andi->
how does this encrypty-in-place stuff work that Android is doing?
<samueldr>
it's complicated
<samueldr>
there is no "one" encrypt-in-place thing
<samueldr>
and it only covers user data
<samueldr>
so they still have a system to boot to to do more complex stuff
<andi->
so as long as the initramfs (with the installer UI/whatever) fits into the bootloader/kernel partitions we could just do "as normal"?
<samueldr>
that's almost the plan I have in mind
<samueldr>
but it needs to be fleshed out and implemented
<andi->
details ;-)
<samueldr>
a requirement is to allow users to pick multiple partitions on "hostile" hardware to wrangle into an LVM volume, then another option is to add LUKS support for volumes, etc
<samueldr>
e.g. on android you probably want to pick the [system{,_a,_b}, userdata] partitions to maximize space use
<dotlambda>
dxb: Did you get lisgd to work?
bennofs_ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
<dxb[m]>
haven't tried yet :p i can try right now though. one sec
<dxb[m]>
dotlambda some gestures worked with /dev/input/event3 but not all
<dxb[m]>
the ones that worked were the swiping between tags
<dotlambda>
as samueldr suggested, you should try /dev/input/by-path/something
<dxb[m]>
oh yeah
<dotlambda>
that won't change anything, but it's better style
<dxb[m]>
also i guess what's probably happening is that the volume and backlight devices aren't correct in the scripts it uses to change those
<dxb[m]>
which is why those gestures wouldn't work
<dotlambda>
i would just try it with lisgd -d /dev/input/event3 -g "1,LR,*,*,R,notify-send swiped lr" -g "echo swipe" and change the gesture accordingly
<dotlambda>
the correct paths for volume etc. will then have to be found out for the sxmo module
<dxb[m]>
so it worked with /dev/input/by-path/platform-1c2ac00.i2c-event
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raspi4 has quit [Quit: Connection closed]
<samueldr>
#121834 in which I finally took the time to just delete some files :|