<tmlind>
inky: m1 has been usable since about january with the corellium hacked kernel patches, mainline support for basic devices might take few more merge cycles
<Entitlement>
tmlind - [ Firestorm Base Instructions ]
<tmlind>
but doing zcat /proc/config.gz | grep CONFIG_COMPAT shows it's is not selected for the corellium kernel.. maybe there's something more to it too
<mighty17>
tmlind does pmic (twl6030) work for u?
<tmlind>
mighty17: yeah it's been working for basic regulators with the mainline kernel for like what close to 15 years?
<tmlind>
hmm maybe more like 12 years :)
<mighty17>
xD tmlind it's not working for me, remember the issues I sent??
<mighty17>
`[ 4.269531] VAUX2_6030: ramp_delay not set`
<mighty17>
even with clock-frequency it doesnt work :(
<mighty17>
`[ 4.312927] twl 0-0048: PIH (irq 152) nested IRQs` i do get this in dmesg, so twl module seems to work
<mighty17>
`<6>[ 0.278228] twl6030: PIH (irq 39) chaining IRQs 368..387` and this is in downstream, do i need to change irq?
<Wizzup>
uvos: inky: hildon-input-method should be in -devel now
<Wizzup>
the new one
diejuse has joined #maemo-leste
diejuse has quit [Remote host closed the connection]
diejuse has joined #maemo-leste
diejuse has quit [Remote host closed the connection]
diejuse has joined #maemo-leste
linmob has joined #maemo-leste
<uvos>
great
linmob has quit [Ping timeout: 240 seconds]
diejuse has quit [Read error: Connection reset by peer]
diejuse has joined #maemo-leste
<diejuse>
Do you guys use Pidgin on Maemo Leste?
<freemangordon1>
sort of
<diejuse>
what app?
<freemangordon1>
pidgin?
freemangordon1 has quit [Quit: Leaving.]
freemangordon has joined #maemo-leste
<freemangordon>
it is in debian folder in apps
<freemangordon>
once you install it ofc
<diejuse>
ok
RedW has joined #maemo-leste
diejuse has quit [Remote host closed the connection]
mardy has quit [Quit: leaving]
mardy has joined #maemo-leste
diejuse1 has joined #maemo-leste
xmn has joined #maemo-leste
diejuse has joined #maemo-leste
RedW has quit [Ping timeout: 240 seconds]
<diejuse>
Is possible to make new icon folds like Debian? I would like to make new categories
<freemangordon>
sure
<freemangordon>
there is even an ui for this, not sure if it is ported already
<freemangordon>
catorize or somesuch
<Wizzup>
catorise?
<freemangordon>
mhm
<Wizzup>
wonder how it works with our 'debian' icon though
<Wizzup>
we did some stuff to make that work as well
<freemangordon>
never used it though
<freemangordon>
and I remember there were some complains back then
<uvos>
hildon desktop just needs to implement the xdg menu spec
<uvos>
then stuff gets catiogrized automaticly
<uvos>
and we can have a maemo category where our stuff goes
<diejuse>
categorise, I will install it
<uvos>
you cant its not ported
<Wizzup>
uvos: I think he wants to customise them
<uvos>
Wizzup: sure xdg menu spec would let you customize it
<diejuse>
I am searching workable game emulators too
<freemangordon>
but he can try to
<uvos>
with any xdg tool
<Wizzup>
uvos: with what tooling?
<uvos>
the lxqt tool should work for instance
<uvos>
but we could write our own then
braenon is now known as branon
<freemangordon>
uvos: I don;t understand that obsession to move away from tools that were proven to work on maemo
<freemangordon>
why the hall we shall write a new tool when we already have one?!?
<freemangordon>
*hell
<uvos>
i dont understand you obsession with perserving dead fremantle code
<freemangordon>
because it is code that works
<uvos>
because it will integrate with debian
<freemangordon>
it was tested and it was made woth mobile in mind
<uvos>
and its all pretty bad
<uvos>
honestly
<freemangordon>
says who?
<uvos>
i do
<uvos>
most of it is not that well concieved
<uvos>
and interoperating with plamo and phosh has real benefits
<uvos>
for all of us
<freemangordon>
ok, lets made it better then, instead of throwing the baby aong with the water
<freemangordon>
sorry, but project goal is to make Fremantle ancestor. Compatibility with other projects is good to have, but not a must
<uvos>
interoperating with other uis incl. mobile and desktop ones requires us to throw away the totaly custom nih way everything works on fremantle
<uvos>
that is not my goal
<freemangordon>
and there is a reason for that custom code - no linux code has the same level of integration and functionality on mobile
<freemangordon>
uvos: that's why I said "project goal"
<diejuse1>
From my humble opinion, I think a good goal would be to move the applications that Maemo 5 already had.
<freemangordon>
exactly
<freemangordon>
if by move you mean port
<uvos>
its just sill
<diejuse1>
I think it is not a good idea to have Maemo Leste installed and miss Maemo 5 applications.
<uvos>
y
<freemangordon>
uvos: and most if not all of our users seem to support that
<uvos>
all that achieves is require us to maintian everything ourselvs forever
<uvos>
instead of leveraging the comunitys work
diejuse has quit [Ping timeout: 240 seconds]
<uvos>
you could have like 95% of fremantle features with 20% of its code
<uvos>
by leveraging modern linux-desktop technologys
<freemangordon>
no matter if you think it is silly, crazy or whatnot. Also, you lack maemo/fremantle experience as a user, so I think you cannot really judge on wht shall stay or what shall be remove
<freemangordon>
sorry, but desktop is not mobile
RedW has joined #maemo-leste
<freemangordon>
uvos: anyways, lets agree to disagree and move on
<uvos>
desktop is not mobile is a pointless tautologoy that has nothing to do with the behind the seans tech that drives the former
<freemangordon>
pointless? sorry, but UI/UX on desktop has almost nothing in common with UI/UX on moblie
<freemangordon>
the same comes fro power usage requirements, the same comes for the fact that you have phone functionality
<diejuse1>
freemangordon: I agree
<freemangordon>
being able to call 112/911 for example should be something to be done even if the device is melting in your hends, if possible
<freemangordon>
in my book, mobile phone is not a laptop with a modem attached
<uvos>
none of this has even the slightest bearing on implementing xdg specs seriously
<freemangordon>
could be
<diejuse1>
As a heavy mobile user, I think the greatest thing about Maemo Leste is using nice Linux applications to see and use with your fingers, such as Androir or IOS.
<brabo>
time to move to libera.chat
<freemangordon>
mhm
<buZz>
14:24:13 -ChanServ(ChanServ@services.libera.chat)- #maemo-leste is now registered to buZz.
<freemangordon>
looks like
<brabo>
hostile takeover done, staff resigned and moved there
<freemangordon>
buZz: could you transfer that to Wizzup
<freemangordon>
?
<buZz>
yes
<Wizzup>
uvos: freemangordon: I think we can doboth, and just do a better job than nokia did
<buZz>
once he's in ;)
<Wizzup>
as uvos is doing for example with h-d wrt wm specs
<buZz>
freemangordon: just consider it a placeholder for now
<buZz>
(i did the same on OFTC, fyi)
<freemangordon>
buZz: ok. And thanks :)
<Wizzup>
freemangordon: we're getting rid of a lot of hacks, which I think is good
<freemangordon>
Wizzup: I think you know my stance on the matter and it hasn't changed lately.
<freemangordon>
sure it is
<Wizzup>
now also in libsdl
<Wizzup>
freemangordon: what I mean is that I think we're actually doing bot
<Wizzup>
both
<Wizzup>
fremantle compat + better adhere to specs and integration
<freemangordon>
My point is - if we can do the same without hacks, fine. But, removing functionality because upstream does not support it is something I won;t agree on
<Wizzup>
well I don't think that was being argued for, right?
<Wizzup>
we could implement the xdg spec and treat the hildon group specially for example
<Wizzup>
that way it'd be the same
<freemangordon>
that's my feeling, so the discussion
<Wizzup>
ok
<freemangordon>
lets move to libera.chat :)
<Wizzup>
I can do that in abit
<freemangordon>
sure
<Wizzup>
too bad, we have lots of people here :)
<Wizzup>
hope they'll follow along
<bencoh>
I feel like I'll have 2x open windows in the next few months ...
<freemangordon>
yeah
<inky>
wait wait why would you move? i don't mind as long as it is IRC (open protocol, availability of open source clients) but from marketing perspective, why would you move if you have 88 people in room here?
<Wizzup>
we can at least be in both for a bit, I'd also like to see how it all pans out and be a bit more idle
<tmlind>
if it gets too complicated, there's always the option of minimal kernel + kexecboot + kexec binary, should fit into 2MB or whatever the kernel image size limit was
<uvos>
that would also make managing leste simpler
xmn has quit [Ping timeout: 265 seconds]
<uvos>
if everything uses kexecboot
<uvos>
but its ugly imo
* tmlind
has not looked back since kexecboot
<Pali>
iirc kexec is broken on n900
<tmlind>
oh really?
<Wizzup>
I think the u-boot functionality is neat and we should try to keep it, if it's only USB_DM, can they drop just that until it gets ported?
<tmlind>
i have not tried kexec on omap3 for like 10 years, sorry..
<Pali>
bencoh, Wizzup: maybe should express your arguments on u-boot ML
<Wizzup>
I can/will, but not yet -- I am taking care of some other things ATM
<Pali>
ok...
<freemangordon>
wait, isn't USB being converted to DM by one of the pending patches?
diejuse1 has quit [Ping timeout: 265 seconds]
<tmlind>
Pali: just tested, kexec works fine for me with v5.13-rc2
<uvos>
freemangordon: btw using the gtk wrapper for XGrabKeyboard instead of XGrabKeyboard directly dose introduce one obscure bug
<freemangordon>
which is?
<uvos>
freemangordon: if tklock is run in an xsecurity extrension context (why!? :P) it will think its getting the grab and working instead of exiting with error
<uvos>
very obscure i know
<uvos>
but i noticed it while reading the gtk code
<freemangordon>
uvos: not sure I understand
DPA has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
<uvos>
a x application inn an xsecurity extrension context cant hold a grab or get any key input whatsoever except if the user is typing directly into the window
<freemangordon>
not to say it should not exit with error
<uvos>
and also cant ovveride redirect itself
<uvos>
so tklock in sutch a context will be very broken
<uvos>
XGrabKeyboard will fail with allready grabbed in this context
<uvos>
but the gtk funciton spoofs this and returns grab sucess instead