<sicelo>
none specifically. i just recall the issue of emergency calls has come up here a couple of times
<freemangordon>
yeah
<rafael2k>
/etc/pulse/default.pa -> set "set-default-sink 1
<rafael2k>
"
<rafael2k>
to get audio output in pp with the correct output
Oksanaa has joined #maemo-leste
<rafael2k>
Wizzup: if you end up finding a way to have our pulse audio custom configs... apart of "load-module module-switch-on-port-available" in system.pa, it would be nice to have this "set-default-sink 1" in default.pa
pere has quit [Ping timeout: 256 seconds]
_inky has quit [Ping timeout: 256 seconds]
inky_ has quit [Ping timeout: 256 seconds]
<rafael2k>
and as far as I can check with v4l tools, /dev/media0 is the video decoder hardware, and /dev/media1 is the camera, which all seem to work
inky_ has quit [Remote host closed the connection]
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
<bencoh>
freemangordon: if anything, I'd have a look at fcamera
<bencoh>
(regarding camera)
<bencoh>
well actually it depends on what you want to use it for, I dunno if it would be suitable for live camera streaming or video recording
<rafael2k>
freemangordon: tks!!
<bencoh>
does omap3camd levarage the ISP for debayering?
<bencoh>
leverage*
<bencoh>
(ie demosaicing)
<freemangordon>
I think so
<freemangordon>
all post-processing happens in omap3camd and IIRC part of it is HW accelerated through ISP
<sicelo>
Is ISP open/documented?
<freemangordon>
yes
<freemangordon>
bencoh: I see no debayer module, so I guess we get RGB from cameras
<freemangordon>
or it is done implicitly
<sicelo>
There was a libcamera talk at FOSDEM, and Laurent wished he could support omap SoCs there
<freemangordon>
ISP is already supported in kernel
<freemangordon>
not sure to what extend though
<Wizzup>
bencoh: yeah fcamera is great
<freemangordon>
also, n900 is very tricky in terms of cameras
<freemangordon>
as front/back switch is done through gpio
<freemangordon>
last time I checked this was not handled properly in the kernel
<sicelo>
I think fcamera was using very custom stuff, including kernel modules. Hence Pavel sort of gave up on it for his N900 camera poc
<rafael2k>
cedrus hw acceleration seems to be working with VA libva-v4l2-request in PP, at least up to what I could test with H.264
<freemangordon>
yes, it was using custom kernel modules
<freemangordon>
Wizzup: were you able to come up with some idea on how to use xkb data? like, we can live without nokia etc kbd models
<freemangordon>
as we already have that in /etc/default/keyboard
<freemangordon>
but, I am not able to grok how to get the available layouts based on keyboard model
<freemangordon>
maybe I am missing something, dunno
<Wizzup>
freemangordon: no, didn't really think about it much more, do you mean base or base.xml file?
<Wizzup>
I think I was kind of able to parse the base file in my head, where the repeating lines are additional layouts
<Wizzup>
but we can just add stuff to base.xml as far as I can concerned
<Wizzup>
we already fork xkb-data anyway
<freemangordon>
base.xml is not the same as base, in terms of data/logic
<freemangordon>
but ok, I will see what I can come up with
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 250 seconds]
inky_ has quit [Ping timeout: 256 seconds]
_uvos_ has joined #maemo-leste
<_uvos_>
please use libcamera. the pp camera and the n900 camera should be usable though libcamera with the mainline kernel in basic fashion (at least filters and sensor color grading will be needed for n900 to get resonable pictures)
<Wizzup>
agreed
<_uvos_>
also mapphone cameras will need libcamera too
<rafael2k>
Wizzup: any problem with the pp kernel PR, lemme know
<_uvos_>
btw there was a driver for omap4 video decoding in linux mainline staging, and there is a foss ti lib to use it
<_uvos_>
so should be possible to get that going for hw encode
<humpelstilzchen[>
not remoteproc I hope?
<rafael2k>
libcamera++
<rafael2k>
there is even a gst plugin!
<rafael2k>
but we'll need newer meson version, and prolly other newer stuff
_uvos_ has quit [Remote host closed the connection]
xmn has joined #maemo-leste
<Wizzup>
rafael2k: no problem, just busy this morning, will get on it in a few hours
<sicelo>
IIRC, libcamera doesn't support omap* camera subsystem yet. Someone will have to add it
_uvos_ has joined #maemo-leste
<_uvos_>
omap iss should work fine in libcamera via mcc/v4l to get raw data
<_uvos_>
so the omap side is there
<_uvos_>
you need support for dealing with particularits of the datastrem ofc
<_uvos_>
per sensor chip
<_uvos_>
ie debayer/ color grading, binning what have you
<_uvos_>
and for sane performance you need to use ducati/ whatever omap 3 hw block is
_uvos_ has quit [Read error: Connection reset by peer]
_inky has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
Oksanaa has quit [Ping timeout: 256 seconds]
Oksanaa has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
_inky has joined #maemo-leste
sicelo_ has joined #maemo-leste
<bencoh>
freemangordon: no, we get bayer from camera
<bencoh>
freemangordon: fcamera saves raw by default (it allows saving a processed version as well, but that's custom processing)
<bencoh>
as for video on droid4, iirc it's based on remoteproc, yes
<bencoh>
or the TI remoteproc equivalent from back then (2012)
<bencoh>
is libcamera really "good" btw? or is it bloated like the android camera subsystem?
<Wizzup>
uvos: bionic battery really lasts for a long time
<freemangordon>
Wizzup: could it be related to the latest reverts?
<Wizzup>
freemangordon: not just that, but also
<Wizzup>
bionic I think in general idles a bit better somehow
<Wizzup>
it's surprising how well the bionic works
rafael2k has quit [Ping timeout: 240 seconds]
rafael2k has joined #maemo-leste
<bencoh>
Wizzup: should we drop the droid4 and start working on a bionic hw keyboard? :]
<Wizzup>
bencoh: I think working on a virtual keyboard that can be shown while the app is resized and visible (not blurred) would be helpful
<Wizzup>
including support for ctrl etc
<bencoh>
oh, talking about keyboards, ibus has support for emojis (with a clickable window). I wonder if integrating the hildon keyboard in some ibus plugin would give better results
<Wizzup>
uvos probably has some ideas on this too, there is the at-spi stuff
<bencoh>
like, ibus works with any kind of application, be it gtk/qt, or plain X11 (through xmodifiers)
<Wizzup>
buZz: just built navit 0.5.6 on maemo
<Wizzup>
seems to work
<dsc_>
Wizzup: perhaps the app does not have to be resized for virtual keyboard to show up
<dsc_>
android behavior is to overlay the keyboard as-is
<Wizzup>
dsc_: well, if you have a terminal and you're typing at the bottom, how does it work?
<dsc_>
some applications you'd want to resize (terminal apps), some application may choose to provide their own keyboard (terminal apps?), some applications dont want to resize (browers)
<dsc_>
if you want to follow android behavior, that is
<dsc_>
im just looking at what my phone currently does :P
<Wizzup>
mhm
<Wizzup>
buZz: do you know how specify a vehicle for navit?
<buZz>
eh no , i barely know what navit is :P
<buZz>
i found attempts of myself to get it running on a zipit z2 back in 2019
<bencoh>
offline routing works well for marble, and iirc they use the same routing engine
<Wizzup>
buZz: well if you have some time maybe you can try it with leste, we're close to supporting various tablets as well, so could be nice for in-car nav somehow :p
<bencoh>
(aka monav)
<bencoh>
(which reminds me I should probably update my monav routing database with the data from modrana)
* Wizzup
never used routing on n900
<buZz>
bencoh: hmm yeah it does use the same engine it seems, not sure what went wrong
<buZz>
the navit guys seem kinda active anyway, so it felt like a nice route towards my non-maemo related goal of recycling old tomtoms :P
<rafael2k>
I would use my pp with maemo to play music and may be at the same time do some gps assisted routing : ))
<buZz>
does the pinephone have a fm transmitter? :P
<rafael2k>
dont make me cry
<rafael2k>
:(
<buZz>
ah no :(
<rafael2k>
:P
<buZz>
some tomtoms do have one :)
<rafael2k>
how i miss it
<rafael2k>
thaaat is cool
<buZz>
not quite sure those work for what i want
<rafael2k>
could even transmit some afsk data to the nearest buddies... eheheheh
<rafael2k>
when I have my sabbatical year I'll do a cover for the pp just like the lora one, but with a true generic radio, with i/q in and out
<rafael2k>
<- trying to compile libcamera to see if it works with pp
macros__ has joined #maemo-leste
<rafael2k>
this libcamerasrc element for gstreamer would be really useful if it works... we could have camera ui much easily ported and much more generic (instead of hardcoding tons of specific ioctl()'s for each supported device)
<buZz>
rafael2k: hahaha, hackrf pp cover? :D
<rafael2k>
exactly
<buZz>
10w PA with seperate battery
<buZz>
:D
<rafael2k>
certainly I will borrow some ideas from the pp keyboard, just not the catching fire part
<rafael2k>
big battery and powerful PA
<buZz>
its catching fire? :P
<rafael2k>
mine did
<rafael2k>
:/
<buZz>
howso?
<buZz>
overeager usb-c pd? :P
<rafael2k>
like 2 minutes after being the charger, smoked
<buZz>
'120W? yessirrr'
<rafael2k>
:PP
<buZz>
does it still work? :)
<rafael2k>
sure, I use as weight for the papers in the table now
<rafael2k>
(pine64 is sending me a new mainboard to change myself... lets see)
macros__ has quit [Ping timeout: 260 seconds]
macros__ has joined #maemo-leste
<buZz>
ah sweet :)
<rafael2k>
I see in libcamera some specific support for "pipelines", like ipu3, raspberrypi, rkisp1, simple, uvcvideo and vimc, and some enable "IPA" modules, whatever it is, but I doubt specific pp (or N900) support will be perfect out-of-the-box
<rafael2k>
but at least the infrastructure to add proper support for specific hardware is that, which is nice
<rafael2k>
(it is still compiling, btw, including the QT app)
<rafael2k>
(i'm compiling in bullseye chroot for the sake of lazyness... if it works fine, we backport it to beowulf)
System_Error has quit [Ping timeout: 276 seconds]
<sicelo>
i think pp should have the best support actually ... because that's the "main" device throughout all FOSS projects nowadays
<sicelo>
(support in libcamera, that is)
macros__ has quit [Quit: Konversation terminated!]
DPA has quit [*.net *.split]
eloy has quit [*.net *.split]
uvos has joined #maemo-leste
eloy has joined #maemo-leste
DPA has joined #maemo-leste
scops has quit [Ping timeout: 240 seconds]
optix has quit [Ping timeout: 245 seconds]
humpelstilzchen[ has quit [Ping timeout: 245 seconds]
tvall has quit [Ping timeout: 250 seconds]
BlagovestPetrov[ has quit [Ping timeout: 250 seconds]
mighty17[m] has quit [Ping timeout: 250 seconds]
devrtz[m] has quit [Ping timeout: 256 seconds]
calebtheythem[m] has quit [Ping timeout: 252 seconds]
MartijnBraam[m] has quit [Ping timeout: 268 seconds]
<rafael2k>
megapixels is pretty hacky stuff, all hardcoded, but current state (not 5.17 of some days ago) did not have proper v4l functions to handle probing the camera parameters and so on
<uvos>
rafael2k: ok great
<uvos>
maybe its easiest to get some camera ui with libcamera going on rpi first
<rafael2k>
good... so we can proceed with the idea of pluging camera-ui to gst-libcamera... I plan to do the kernel worklifting soon
<uvos>
or uvc
<rafael2k>
sure, that can go in parallel
<rafael2k>
gst-libcamera + libcamera itself
<uvos>
ok
<rafael2k>
I'll check what might be better, backport the patches, or just go to 5.17...
<uvos>
Wizzup: no worrys :) i just thought you forgot to awnser
<Wizzup>
uvos: my pretty fast remark was regarding your lock question
<Wizzup>
uvos: ooooh
<Wizzup>
uvos: I thought of lock _screen_
<Wizzup>
lol
<uvos>
oh
<uvos>
haha
<uvos>
:P
<uvos>
Wizzup: right ok so we dont have tmlinds patch
<uvos>
Wizzup: ok ill have to build it then to try it on bionic
<Wizzup>
I can add it
<uvos>
ok thanks!
<rafael2k>
Wizzup: please don't forget the no-keyboard-burn kernel for pp
<rafael2k>
: ))
<uvos>
rafael2k: vat? what happend there? link?
<rafael2k>
uvos: see my PR to pine64-kernel
scops has joined #maemo-leste
<Wizzup>
rafael2k: not forgetting, been busy
<rafael2k>
there are some scare new pp keyboard patches that landed a couple of days ago to make the keyboard behave better... like limiting power and stuff like that
<rafael2k>
no rush...
<rafael2k>
it was my fault prolly, but having better software support always make hardware smoke more difficult
humpelstilzchen[ has joined #maemo-leste
<Wizzup>
let me finish dinner and then I'll do it
* dsc_
looks at the clock
optix has joined #maemo-leste
tvall has joined #maemo-leste
<rafael2k>
here is wine time already... just put my daugher to sleep : )
<uvos>
rafael2k: so sphone dosent work wrt profile switch anymore?
<uvos>
could you paste pactl list?
<uvos>
on pp
<uvos>
ofc
<rafael2k>
uvos: good, lemme test again now I set the default pa device
<Wizzup>
dsc_: second dinner, had some leftovers :)
<uvos>
id better not tell anyone when i had dinner then....
<uvos>
rafael2k: also sphone log
<uvos>
rafael2k: killall sphone ; sphone -v
<rafael2k>
uvos: not working
<rafael2k>
ok
mardy has quit [Quit: WeeChat 2.8]
<uvos>
it still works on mapphone
<rafael2k>
sphone: route-pulseaudio: failure: set ucm profile to Voice Call No such entity
<rafael2k>
sphone: route-pulseaudio: failure: set ucm profile to HiFi No such entity
<Wizzup>
that is 1456273b2f82b5e85324411fb189a57273d772b0 (your HEAD) and 3f0d484ed6b51c664045bd737e647e8e03277570 (current repo head / maemo-kernel-5.15.0tag)
<rafael2k>
hum
<rafael2k>
could you just rebase using "upstream"? I dunno what is wrong
<Wizzup>
sure, but you have a merge commit merging in the old branch/tag
<rafael2k>
is liblocation integrated with gpds somehow already?
<uvos>
it uses gpsd
<rafael2k>
gpsd seems to be working fine here
<rafael2k>
ah, ok
<uvos>
yes gpsd works fine
<Wizzup>
liblocation is a lib that does some extra stuff but the data comes from gpsd ultimately, but there is some dbus stuff as well
<uvos>
really we should port it to geoclue instead
<Wizzup>
(the gpsd dbus stuff isn't that great)
<uvos>
note that liblocation is just a dumb proxy for gpsd atm
<Wizzup>
it does do more stuff than just being a proxy
<rafael2k>
liblocation seems ok to me, I remember its API from long time ago when I played with it with the N900
<Wizzup>
it contains some ui elements, a status applet, and other stuff
<Wizzup>
and it will stop gpsd when it's not required, etc
<Wizzup>
I don't know much about geoclue so cannot comment
<uvos>
geoclue dose all of this + has working network location sources and sensor fusion
<rafael2k>
so better stick with liblocation :P
<uvos>
sure ui elemetns etc, i mean liblocation and the location deamon do little besides proxy gpsd atm
<uvos>
ofc the ui and sutch uses it
<Wizzup>
uvos: yes, we need to look into geoclue to some degree
<rafael2k>
right
<Wizzup>
it probably won't help us with low level integration though
<uvos>
wdym?
<uvos>
low level integration
<uvos>
mostly we can ditch location deamon, and port liblocation to geoclue to be just a legacy shim
<uvos>
and then have the ui bits use geoclue directly
<uvos>
then all the desktop/phos/plamo applications will just work
<Wizzup>
I don't have the energy to go into this now, I think we discussed this at length, and we need a way to be able to just turn off gps and prevent apps from using gps when users doesn't want it on
<Wizzup>
and yes, geoclue probably has a place in all of this
<uvos>
right geoclue provdes this
<uvos>
:)
<uvos>
preventing apps from using gps requries more ofc
<rafael2k>
Wizzup: looking at other updates, it was always bla.la.0-{1,2,3}...
<rafael2k>
I mean.. it does not matter tbh, just cosmetics...
<rafael2k>
btw, looking at libcamera, to have really proper support, we need to create a pipeline there, in order, for example, to use hardware acceleration together with the frames captures
<rafael2k>
*captured
<Wizzup>
rafael2k: I put the minor version in there
<rafael2k>
Wizzup: I like
<Wizzup>
rafael2k: I think we should, but I've been sloppy about some of it
optix has quit [Quit: You have been kicked for being idle]
<rafael2k>
Wizzup: cool, I agree, next PR I'll do this too
optix has joined #maemo-leste
<Wizzup>
uvos: sounds good, but let's not do it now