pagurus has quit [Ping timeout: 240 seconds]
sunshavi has quit [Ping timeout: 256 seconds]
pagurus has joined #maemo-leste
ikmaak has quit [Ping timeout: 256 seconds]
ikmaak has joined #maemo-leste
sunshavi has joined #maemo-leste
jk__000 has joined #maemo-leste
jk_000 has quit [Ping timeout: 256 seconds]
pagurus has quit [Ping timeout: 256 seconds]
Pali has quit [Ping timeout: 272 seconds]
pagurus has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
tvall has quit [Quit: You have been kicked for being idle]
xmn has quit [Ping timeout: 272 seconds]
Twig has joined #maemo-leste
pere has joined #maemo-leste
<sicelo> sixwheeledbeast: btw, for the battery issues, bq27200.sh and zzztop from Fremantle do work on Leste ( https://github.com/maemo-leste/bugtracker/issues/170 )
<sixwheeledbeast> sicelo: zzztop is just a perl script so I had already pulled the source straight to usr/local/bin. there was nothing unusual just no C0 state, 99% C1. I will look for bq27200.sh
<Wizzup> I think you will find little in userspace for n900 pm, it's all kernel stuff
<Wizzup> but if you just want to measure the battery, that could work
<sixwheeledbeast> What I haven't figured out yet is where packages come from in leste. how do you decide if they are from devuan or leste/ham somewhere else. or is that tbc?
Twig has quit [Ping timeout: 260 seconds]
Twig has joined #maemo-leste
<Wizzup> sixwheeledbeast: it's not tbc
<Wizzup> sixwheeledbeast: so we have devuan (which is mostly debian) as a repo
<Wizzup> and then there is the normal leste repo, with core packages
<Wizzup> and then there is the leste extras repo, with extras
<Wizzup> ham stuff can come from leste repo and leste extras repo
<Wizzup> but pkgs are only shown in ham if they are specifically marked/built to be, currently
<sixwheeledbeast> right it makes more sense now.
Oksanaa has quit [Ping timeout: 240 seconds]
Oksanaa has joined #maemo-leste
Pali has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 250 seconds]
<sicelo> so n900 torch can be enabled with manual i2c commands at least. maybe i'll make a Desktop-Command-Execution-Widget button for it :p
pere has joined #maemo-leste
<Wizzup> sicelo: or kernel driver?
<sicelo> the driver is mostly fine actually, but the whole thing is interconnected with v4l ...
<sicelo> i'll look at it some day when i have more time, but it's nice to have access to a torch already
<Wizzup> right, maybe it can be done with v4l control?
<sicelo> not until dts work :-)
<sicelo> the thing is - currently the torch doesn't appear anywhere when you modprobe the driver, even though there are no errors when loading it
<sicelo> it's a long thread that i'll come back to some time in the future
<Wizzup> ok
<sicelo> i have a note of N900 things i want to work on, so i won't forget. this is one of them
<Wizzup> ok, should we make some into issues?
<sicelo> mmm, i guess it won't hurt
<sicelo> roughly in order of priority, i want to look at wl1251-cal again, then infrared (it oopses when you use it), torch, fm radio, bt, host mode, cameras, port modem to modemmanager
<sicelo> it's a tall order, but i'll be happy to achieve those i can achieve. maybe by that time no N900 in the world :p
<Wizzup> why modemmanager? the n900 ofono port is in great shape
<sicelo> just for fun :-)
<Wizzup> ok
<sicelo> that's why it's towards the end of the list
<Wizzup> if you're looking for fun. help with d4 ofono is appreciated too
<Wizzup> I'm reached out to folks on ebay about droid4/droid3
<Wizzup> one confirmed 24
<Wizzup> so that's cool
<sicelo> my droid4 is moody, so yeah :-)
<sicelo> plus, there are many people working on the droid 4 already, while n900 gets less love nowadays, understandably, since resources ... so i want to keep as much of it in good shape as much as my limited skillset allows, if only for nostalgic purposes (and learning, of course)
<Wizzup> check
<bencoh> 24 droid4s ?!
<sicelo> Wizzup: so when rotating, i was under the impression that xinput map-to-out put does magic for us? or still need to manually specify a coordinate transformation matrix?
<bencoh> are you buying bulk quantities?
<Wizzup> bencoh: trying to
<bencoh> neat
<Wizzup> well I'm really hoping to have someone else take care of fixing and sending them to people
<sicelo> at least on pmos, map-to-output then rotating with xrandr doesn't seem to keep ts in sync with screen rotation (this is on i3, but i doubt wm matters much here, or not?)
<bencoh> (I'm starting to think I'd be better with a new one as well btw, unless I manage to fix the usb issue, but it sounds super annoying to fix without an out-of-band serial console)
<bencoh> oh, those are broken droid4s?
<Wizzup> I can try to send you one when I am home (for a total of three days)
<Wizzup> bencoh: some of them are, others are fine
<Wizzup> I got 12 broken ones for ~8 usd a piece (either missing battery or broken ts iirc)
<Wizzup> well, I don't -have- them yet
<bencoh> sounds like a decent deal
<Wizzup> think so
<Wizzup> the guy wanted like 14usd per piece but I said that was too much :)
<sicelo> that's cheap! 8usd for a device.
<Wizzup> sicelo: with some kind of defect mind you
<Wizzup> but yeah I reached out to a few more ebay sellers
<sicelo> still. here you can't get ANY device for that kind of money :p
<Wizzup> yeah a colleague in the us is helping sending
<sicelo> droid 4 xinput has,
<sicelo> ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
<sicelo> ⎜ ↳ Filtered Touchscreen id=7 [slave pointer (2)]
<sicelo> what's filtered touchscreen?
<sicelo> maemo leste, btw
[TheBug] has quit [Changing host]
[TheBug] has joined #maemo-leste
guile-guest has joined #maemo-leste
<Wizzup> sicelo: sorry, was afk
<Wizzup> sicelo: that's what it looks like after the touchscreen buttons thing is applied
<sicelo> ah
Livio has joined #maemo-leste
xmn has joined #maemo-leste
<Wizzup> pushing keyring pkg to stable
TonyStone has quit [Ping timeout: 240 seconds]
Livio has quit [Ping timeout: 256 seconds]
TonyStone has joined #maemo-leste
TonyStone has quit [Ping timeout: 260 seconds]
guile-guest has quit [Quit: Connection closed]
TonyStone has joined #maemo-leste
TonyStone has quit [Ping timeout: 268 seconds]
TonyStone has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> sicelo: "so when rotating, i was under the impression that xinput map-to-out put does magic for us? or still need to manually specify a coordinate transformation matrix?" no the code i added to h-d is roughly equivalent to map-to-output
<uvos> but you have to apply the correct transformation matrix to libinput (ie before x) so that the ts and the display are in sync coordinate wise
<sicelo> i'm doing it on i3. i couldn't get it working. so for the time being, i'm using xinput setprop for the transformation matrix after rotating
<uvos> or the evdev transfomration matrix if you insit on using the legacy evdev input stack
<sicelo> no idea why map-to-output doesn't work
<uvos> the xinput tranformation matrix is independant of these
<uvos> how is it not working exactly
<uvos> also what device
<uvos> also what input stack
<sicelo> N900. map-to-output doesn't show any errors, but after rotating the display with xrandr --output DPI-1 --rotate left, for example, ts is still in original 'direction' until i do an xinput setprop
<uvos> wait dose xrandr work on n900 now?
<Wizzup> (same question from me)
<Wizzup> maybe he uses modesetting
<uvos> anyhow what input stack
<sicelo> yes this is on pmOS, modesetting yes. rotation doesn't work in what mode? i thought it was just powervr that has issues?
<uvos> nah its omapddx
<uvos> not pvr
<uvos> that has issues
mardy has quit [Quit: WeeChat 2.8]
<sicelo> libinput Calibration Matrix (268): 1.109179, 0.000000, -0.055283, 0.000000, -1.192340, 1.081266, 0.000000, 0.000000, 1.000000
<sicelo> so i guess, libinput
<uvos> dosent mean x is using it
<uvos> so your flipping the xcord in libinput
<uvos> er y
<uvos> i assume yor xinoput matrix is idenity
<uvos> (at boot)
<uvos> and randr has your orientation as "normal"
<freemangordon> modesetting rotation works on n900
<freemangordon> as it is using shadow buffer to rotate
<freemangordon> ]it does SW rotation that's not related to omapdrm or pvr
<sicelo> interesting. i thought pmOS was using omapdrm
<freemangordon> it is
<freemangordon> it is just not using it to rotate
<freemangordon> as VRFB is not supported in omapdrm, only in omapfb
<freemangordon> VRFB is next thing I am going to work after abook
<sicelo> alright. i wonder what i was rotating with on debian + TI blobs + sway. not omapdrm either then
<freemangordon> TI blobs version?
<freemangordon> 1.17?
<sicelo> yes
<freemangordon> SW rotation, again
<freemangordon> the same as modesetting
<sicelo> i understand now :-)
* freemangordon is back to watching european masters, ttyl :)
Twig has quit [Ping timeout: 240 seconds]
<uvos> sway uses gl to render eatch surface as rotated onto an unrotated framebuffer
<uvos> unredirection breaks but its not software
<uvos> anyhow its not relevant, its not related to how unaccelerated x rotates itself
xmn has quit [Ping timeout: 256 seconds]
System_Error has joined #maemo-leste
Pali has quit [Ping timeout: 256 seconds]