| 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 ) | 11:35 |
|---|---|---|
| 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 | 11:40 |
| Wizzup | I think you will find little in userspace for n900 pm, it's all kernel stuff | 11:40 |
| Wizzup | but if you just want to measure the battery, that could work | 11:40 |
| 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? | 11:43 |
| Wizzup | sixwheeledbeast: it's not tbc | 12:15 |
| Wizzup | sixwheeledbeast: so we have devuan (which is mostly debian) as a repo | 12:15 |
| Wizzup | and then there is the normal leste repo, with core packages | 12:15 |
| Wizzup | and then there is the leste extras repo, with extras | 12:15 |
| Wizzup | ham stuff can come from leste repo and leste extras repo | 12:15 |
| Wizzup | but pkgs are only shown in ham if they are specifically marked/built to be, currently | 12:16 |
| sixwheeledbeast | right it makes more sense now. | 13:18 |
| 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 | 16:39 |
| Wizzup | sicelo: or kernel driver? | 17:02 |
| sicelo | the driver is mostly fine actually, but the whole thing is interconnected with v4l ... | 17:03 |
| sicelo | i'll look at it some day when i have more time, but it's nice to have access to a torch already | 17:04 |
| Wizzup | right, maybe it can be done with v4l control? | 17:04 |
| sicelo | not until dts work :-) | 17:04 |
| 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 | 17:05 |
| sicelo | https://linux-arm-kernel.infradead.narkive.com/MHM45sAV/drivers-media-i2c-adp1653-c-does-not-show-as-dev-video-or-v4l-subdev | 17:05 |
| sicelo | it's a long thread that i'll come back to some time in the future | 17:05 |
| Wizzup | ok | 17:06 |
| sicelo | i have a note of N900 things i want to work on, so i won't forget. this is one of them | 17:07 |
| Wizzup | ok, should we make some into issues? | 17:07 |
| sicelo | mmm, i guess it won't hurt | 17:08 |
| 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 | 17:10 |
| 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 | 17:11 |
| Wizzup | why modemmanager? the n900 ofono port is in great shape | 17:11 |
| sicelo | just for fun :-) | 17:13 |
| Wizzup | ok | 17:13 |
| sicelo | that's why it's towards the end of the list | 17:13 |
| Wizzup | if you're looking for fun. help with d4 ofono is appreciated too | 17:13 |
| Wizzup | I'm reached out to folks on ebay about droid4/droid3 | 17:13 |
| Wizzup | one confirmed 24 | 17:13 |
| Wizzup | so that's cool | 17:13 |
| sicelo | my droid4 is moody, so yeah :-) | 17:13 |
| 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) | 17:15 |
| Wizzup | check | 17:17 |
| bencoh | 24 droid4s ?! | 17:17 |
| 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? | 17:17 |
| bencoh | are you buying bulk quantities? | 17:17 |
| Wizzup | bencoh: trying to | 17:17 |
| bencoh | neat | 17:17 |
| Wizzup | well I'm really hoping to have someone else take care of fixing and sending them to people | 17:17 |
| 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?) | 17:18 |
| 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) | 17:18 |
| bencoh | oh, those are broken droid4s? | 17:18 |
| Wizzup | I can try to send you one when I am home (for a total of three days) | 17:19 |
| Wizzup | bencoh: some of them are, others are fine | 17:19 |
| Wizzup | I got 12 broken ones for ~8 usd a piece (either missing battery or broken ts iirc) | 17:19 |
| Wizzup | well, I don't -have- them yet | 17:19 |
| bencoh | sounds like a decent deal | 17:20 |
| Wizzup | think so | 17:20 |
| Wizzup | the guy wanted like 14usd per piece but I said that was too much :) | 17:20 |
| sicelo | that's cheap! 8usd for a device. | 17:21 |
| Wizzup | sicelo: with some kind of defect mind you | 17:22 |
| Wizzup | but yeah I reached out to a few more ebay sellers | 17:22 |
| sicelo | still. here you can't get ANY device for that kind of money :p | 17:23 |
| Wizzup | yeah a colleague in the us is helping sending | 17:24 |
| sicelo | droid 4 xinput has, | 17:34 |
| sicelo | ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] | 17:34 |
| sicelo | ⎜ ↳ Filtered Touchscreen id=7 [slave pointer (2)] | 17:34 |
| sicelo | what's filtered touchscreen? | 17:35 |
| sicelo | maemo leste, btw | 17:35 |
| Wizzup | sicelo: sorry, was afk | 17:46 |
| Wizzup | sicelo: that's what it looks like after the touchscreen buttons thing is applied | 17:46 |
| sicelo | ah | 17:56 |
| Wizzup | pushing keyring pkg to stable | 18:08 |
| 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 | 21:15 |
| 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 | 21:16 |
| 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 | 21:16 |
| uvos | or the evdev transfomration matrix if you insit on using the legacy evdev input stack | 21:17 |
| sicelo | no idea why map-to-output doesn't work | 21:17 |
| uvos | the xinput tranformation matrix is independant of these | 21:17 |
| uvos | how is it not working exactly | 21:17 |
| uvos | also what device | 21:17 |
| uvos | also what input stack | 21:17 |
| 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 | 21:18 |
| uvos | wait dose xrandr work on n900 now? | 21:19 |
| Wizzup | (same question from me) | 21:19 |
| Wizzup | maybe he uses modesetting | 21:19 |
| uvos | anyhow what input stack | 21:19 |
| sicelo | yes this is on pmOS, modesetting yes. rotation doesn't work in what mode? i thought it was just powervr that has issues? | 21:20 |
| uvos | nah its omapddx | 21:20 |
| uvos | not pvr | 21:20 |
| uvos | that has issues | 21:20 |
| sicelo | libinput Calibration Matrix (268): 1.109179, 0.000000, -0.055283, 0.000000, -1.192340, 1.081266, 0.000000, 0.000000, 1.000000 | 21:20 |
| sicelo | so i guess, libinput | 21:20 |
| uvos | dosent mean x is using it | 21:21 |
| uvos | so your flipping the xcord in libinput | 21:21 |
| uvos | er y | 21:21 |
| uvos | i assume yor xinoput matrix is idenity | 21:22 |
| uvos | (at boot) | 21:22 |
| uvos | and randr has your orientation as "normal" | 21:22 |
| freemangordon | modesetting rotation works on n900 | 21:37 |
| freemangordon | as it is using shadow buffer to rotate | 21:37 |
| freemangordon | ]it does SW rotation that's not related to omapdrm or pvr | 21:37 |
| sicelo | interesting. i thought pmOS was using omapdrm | 21:41 |
| freemangordon | it is | 21:41 |
| freemangordon | it is just not using it to rotate | 21:41 |
| freemangordon | as VRFB is not supported in omapdrm, only in omapfb | 21:41 |
| freemangordon | VRFB is next thing I am going to work after abook | 21:42 |
| sicelo | alright. i wonder what i was rotating with on debian + TI blobs + sway. not omapdrm either then | 21:42 |
| freemangordon | TI blobs version? | 21:43 |
| freemangordon | 1.17? | 21:43 |
| sicelo | yes | 21:43 |
| freemangordon | SW rotation, again | 21:43 |
| freemangordon | the same as modesetting | 21:43 |
| sicelo | i understand now :-) | 21:43 |
| * freemangordon is back to watching european masters, ttyl :) | 21:44 | |
| uvos | sway uses gl to render eatch surface as rotated onto an unrotated framebuffer | 22:33 |
| uvos | unredirection breaks but its not software | 22:33 |
| uvos | anyhow its not relevant, its not related to how unaccelerated x rotates itself | 22:34 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!