<mighty17[m]>
sicelo phosh depends on normal wlroots so it automatically installs it :(
<mighty17[m]>
<buZz> "mighty17: is the flicker also..." <- Well charger isn't working in mainline xD, so this is without charger
<mighty17[m]>
<tmlind> "PVR:(Error): PVRDisplayBufferCre..." <- Also what in the world is this error? I get it quite some times when running apps/games
<mighty17[m]>
<tmlind> "maybe the dsi interface line..." <- Then it wouldn't show display at all? Weirdly if I use clock rate divided by 2 the display works normally
<mighty17[m]>
<uvos> "did you dump the dss regisers in..." <- I don't remember doing that, how'd I check it on mainline?
<mighty17[m]>
Aaaand I spammed irc with matrix replies, extremely sorry guys
joerg has quit [Ping timeout: 245 seconds]
joerg has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
<sicelo>
mighty17[m]: phosh just needs libwlroots to be available. anything can provide it, and phosh won't know/care :-)
<mighty17[m]>
sicelo: but phosh uses wlroots0.12 only idk why
<mighty17[m]>
i even tried using provides="wlroots0.12" in apkbuild
<sicelo>
right. so that's *the* problem :-)
<sicelo>
means you need to be building that wlroots version too
<sicelo>
or, try the wlroots 0.14 phosh - i think it's available already
<mighty17[m]>
apk upgrade?
<sicelo>
maybe not packaged in pmos yet. i don't know
<sicelo>
or maybe i'm jumping the gun, but i seem to think there was some mention of a phosh branch using more recent wlroots
<sicelo>
anyway, for now, 0.12 is clearly your friend
<mighty17[m]>
Will stick to it
l_bratch has joined #maemo-leste
pere has joined #maemo-leste
n900 has quit [Read error: Connection reset by peer]
n900 has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
freemangordon: how did the mime system work in freemantle? i noticed that the xdg mime system is broken or missing in most maemo applications
enyc has joined #maemo-leste
Pali has joined #maemo-leste
<freemangordon>
uvos: there is libhildonmime
<freemangordon>
ity works by using categories, which group mime type, IIUC
<freemangordon>
no, it is a list of mime types that are of specified category
<freemangordon>
os 'images' is gpegs, pngs, etc
<freemangordon>
*jpegs
<uvos>
the lib could parse this list from the desktop files it sees
<freemangordon>
but, adobe/cdr too, for example
<freemangordon>
it parses from packages directory
<uvos>
same
<freemangordon>
but, it already does :)
<uvos>
allready dose what?
<uvos>
parse it from the .desktop files?
<freemangordon>
the problem is that it looks for <osso:category name="documents"/>
<freemangordon>
no, osso-pdf-viewer.xml for example
<freemangordon>
it is in /usr/share/mime/packages
<freemangordon>
seems there is a bug somewhere, pdf viewver should work from modest (to open pdf attachment)
<uvos>
so lx-open catigorizes mimes using .destop files, so it has a catigory image and then it parses all the files and if some applicaiton claimes that bmp is an image it puts the mime there
<uvos>
this has the advantage that lx-open dosent need to know what can be an image
<freemangordon>
smae
<freemangordon>
*same
<uvos>
if a new image format comes arround thats calld erf or something
<uvos>
as sson as an app is installed what handles erf it just works
<freemangordon>
but, do you have an example for that 'category' in .desktop file?
<uvos>
erf as ian image category?
<uvos>
*as an
<uvos>
?
<freemangordon>
dunno
<uvos>
yeah xdg specifies types of mimes
<uvos>
like image/ document/ etc
<freemangordon>
what is the key that identifies a category?
<uvos>
mighty17[m]: so besides the dsi problems whats the general working state of the deivce rn?
<mighty17[m]>
uvos: well i'd like to fix 60hz and the backlight, but idkk what to do
<mighty17[m]>
uvos: sound and light sensor dont work (ie i havent started to work on them yet), cameras dont (thanks to ducati) well everything else works
<uvos>
with the 60hz so i would grab the omap4 datasheet and dump the registers related to the dss
<uvos>
and do the same on android
<uvos>
and see if they are different
<uvos>
and then try and parse the difference
<uvos>
use rwmem its pretty easy to build with the ndk for android
<uvos>
no idea about the backlight
<uvos>
btw if you want we can send you a d4 to mess around with as well
<uvos>
might be usefull to compear stuff and also maybe you can help us improve omap4 support in general
<mighty17[m]>
nah i dont think im the best guy to send a d4 to, d4s are already very rare :P
<uvos>
not that rare but as you wish
<mighty17[m]>
uvos: im kinda sure i have the wrong pwm value, but cant find the correcet one
<uvos>
its connected to a omap4 pwm?
<mighty17[m]>
also did you see the 60hz vid i sent, maybe that'll help debugging (if its like a known issue or smth)
<mighty17[m]>
uvos: gptimer
<tmlind>
mighty17[m]: probably good idea to test also on d4 so you can compare
<mighty17[m]>
d4 and tab2 are quite different
pere has quit [Ping timeout: 245 seconds]
DPA- has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
DPA has joined #maemo-leste
zhxt has quit [Ping timeout: 252 seconds]
<Wizzup>
freemangordon: any idea about fremantle and firewall rules?
<bencoh>
Wizzup: nothing, according to iptables
<bencoh>
ie policy ACCEPT with no restriction whatsoever
<mighty17[m]>
Or maybe uvos it's a 1.9 thing (the artifacting)
<bencoh>
(which is kinda scary tbh)
<bencoh>
I'm not certain it should go into anything "leste" anyway
<uvos>
mighty17[m]: no it happens on d4 on ddk 1.17
<mighty17[m]>
Hildon works with 1.17 now? That's news to me
<uvos>
no
<Wizzup>
bencoh: sorry, not certain what should go into anythign leste?
<uvos>
but it do also have d4's that run debian/sway
<bencoh>
Wizzup: firewall management
<Wizzup>
my mobile isp still gives me public v4s on my phone
<uvos>
on a phone its sane to discard all incomeing by default or?
<bencoh>
I'm not certain leste should take care of that part
<Wizzup>
+ stuff like tor transproxy requires iptable setups
<bencoh>
Wizzup: seriously? neat
<Wizzup>
just looking into nftables vs iptables
<Wizzup>
bencoh: neat in some way, not really for my poor old linux fremantle n900
<bencoh>
Wizzup: I use iptables on fremantle
<Wizzup>
debian buster+ seems to suggest nftables
<bencoh>
you can just drop any incoming connection
<bencoh>
oh, they finally moved to nftables? interesting
<uvos>
iptables is mostly maintinaince mode now i would avoid using it
<uvos>
all desktop distros have swiched afaik
<bencoh>
well, I guess I still live in the past ... time to learn nftables
<bencoh>
I'll probably hate it if it's a pf-like syntax though
<uvos>
no idea my router pc is still on iptables
<uvos>
so yeah im also lazy
<bencoh>
I first heard about nftables 13 years ago, so ... it was about time I guess :D
<freemangordon>
is that kernel-side scripting?
<freemangordon>
Wizzup: I am with bencoh on that - it is not us to deal with FW rules
<freemangordon>
we *may* provide a UI someday for user to have some control
<bencoh>
they already replaced the kernel-side iptables/ebtables/whatever code with a common nft engine, and wrote a compatibility layer for the userspace ip/eb/arp/tables tools; but now users should migrate to the native userspace nft tool
<uvos>
accessing the device via incomeing conecction on cellular is so out there
<bencoh>
the thing is ... once you start fiddling with firewall rules, you will always get in the way of power users
<uvos>
its not "phone" usage at all
<Wizzup>
the point is that the only sane default is to reject all but the necessary input traffic (e.g. ssh maybe)
<Wizzup>
we don't have to do it now, but eventually that will be a default
<freemangordon>
and why not torrents? or RTP?
<Wizzup>
it's pretty easy to add more ports to exclusion via whatever ui/ux you want
<Wizzup>
torrents can work fine through firewalls
<bencoh>
uvos: at some point I used tinc on my phone as well to access from anywhere
<Wizzup>
afaik
<freemangordon>
I want nothing basically in that regard :)
<bencoh>
Wizzup: it's messy as well
<uvos>
bencoh: and you have no poblem configuring the firewall yourself
<uvos>
bencoh: people that do this sort of thing are a very select crowd
<freemangordon>
there is no active FW on fremantle
<bencoh>
uvos: sure, but then I don't want my mobile-ish subsytem to push rules here and there
<freemangordon>
exactly
<freemangordon>
ny moint
<freemangordon>
*my
<uvos>
sure but a config file is suffichent here
<uvos>
no ui nessecary
<uvos>
or cli command
<freemangordon>
as soon as there is no default "restrict everything"
<freemangordon>
as soon as there is such a rule, you should be able to remove it through UI
<freemangordon>
GUI even
<bencoh>
"cli command" probably means trouble, config file might be enough, but then you'll have to make sure you don't break stuff (torrent / SIP / RTP / whatever)
<bencoh>
and since I guess we'll always break something, fmg is probably right
<bencoh>
a simple checkbox in the network/connection panel would work btw
<freemangordon>
mhm
<Wizzup>
I strongly disagree but also don't care to discuss it more atm
<freemangordon>
ok, lets discuss when it comes to it :)
<bencoh>
alright :)
<freemangordon>
I also care more about mime types ATM
<freemangordon>
so, back to
pere has joined #maemo-leste
xmn has quit [Ping timeout: 245 seconds]
<freemangordon>
uvos: I guess x-office-presentation is document, not image, what do you think?
<Wizzup>
sounds like power point slides
<Wizzup>
probably provided by libreoffice
<freemangordon>
sure, the point is which category to put that
<freemangordon>
'documents' or 'images'
<freemangordon>
Wizzup: in terms of libhildonmime that is
<Wizzup>
most debian default behaviour I don't understand :P
<bencoh>
haha, same :)
DPA has quit [Ping timeout: 264 seconds]
<Wizzup>
latest libicd-network-wireguard and libicd-network-tor should support proxying everything (for wireguard, set allowedips to 0.0.0.0/0, for tor, just enable transparent proxying)
<Wizzup>
the tor stuff is still building fwiw
DPA has joined #maemo-leste
<Wizzup>
parazyd: we need to fix the network_modules writing
<Wizzup>
it happens on my d4 now too
<parazyd>
Yep
<freemangordon>
hmm, now the icon is wrong :(
zhxt has joined #maemo-leste
<Wizzup>
hehe... wireguard tunnel system wide and tor system wide transproxy work together
<freemangordon>
so, it kinda 'shapes' the traffic, but allows every application to set its own 'wake' timeout
<freemangordon>
and there is logic that tries to wake-up all the requesting applications at the same moment, vastly saving battery (in theory at least)
<freemangordon>
oh, seems parazyd added thumbnailer to the metapackage, thanks!
<parazyd>
Didn't build it yet
<freemangordon>
yeah
<parazyd>
But feel free to trigger whenever
<freemangordon>
maybe add iphbd and iphb-dkms firsrt
<freemangordon>
though, lemme try if it builds still
<parazyd>
Is it tested on devices?
<parazyd>
Yeah
<freemangordon>
last time I tried was on kenel 4.6 or something
<freemangordon>
parazyd: no, but it is not device dependent
<freemangordon>
at least for 4.19.0-17-amd64 it is fine
<freemangordon>
parazyd: but, how to add dependency to kernel headers?
<Wizzup>
I should go on talk.maemo.org some more
<freemangordon>
hmm?
<parazyd>
freemangordon: "linux-headers" I think
<parazyd>
It's a virtual pkg
<freemangordon>
Wizzup: not that it is bad idea, but why in particular?
<freemangordon>
parazyd: ok, will try
<freemangordon>
E: Package 'linux-headers' has no installation candidate
__20h__ has quit [Ping timeout: 260 seconds]
hallyn has quit [Ping timeout: 240 seconds]
sixwheeledbeast has quit [Ping timeout: 264 seconds]
<parazyd>
Then "linux-headers-amd64 | linux-headers"
<parazyd>
I suppose it doesn't exist on the VM
<parazyd>
But we have it on d4 kernel for example.
<freemangordon>
and what about on the devices?
jessicant has quit [Ping timeout: 265 seconds]
__20h__ has joined #maemo-leste
<uvos>
i would strongly reccomend against something that needs out of tree kernel modules