| 00:13:56 | speachy | efqw: can you run 'amixer contents' on the console please? |
| 00:27:35 | Stanley00 | yes, you may need to check if the sound driver is loaded too |
| 00:28:06 | Stanley00 | on my m5, the module is loaded by the "player" application, so I have to do it manually |
| 00:38:29 | *** | Saving seen data "./dancer.seen" |
| 00:51:06 | | Join Soap_ [0] (~Soap@rockbox/staff/soap) |
| 00:52:55 | | Quit Soap (Ping timeout: 246 seconds) |
| 00:54:05 | | Join Soap [0] (~Soap@rockbox/staff/soap) |
| 00:56:23 | | Quit Soap_ (Ping timeout: 260 seconds) |
| 00:57:01 | efqw | https://www.irccloud.com/pastebin/yQgqdA5q/ |
| 02:00 |
| 02:10:25 | | Quit kugel (Ping timeout: 264 seconds) |
| 02:11:25 | | Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) |
| 02:11:25 | | Quit kugel (Changing host) |
| 02:11:25 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 02:38:33 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:23:20 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 03:25:02 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 04:00 |
| 04:12:33 | Stanley00 | phew... I playing around with the button code for m5 and it's working now (sort of)... yay |
| 04:13:08 | Stanley00 | it was my misunderstood how the button_read_device should return that messed up |
| 04:38:36 | *** | No seen item changed, no save performed. |
| 04:50:10 | | Quit braewoods (Quit: WeeChat 2.8) |
| 05:00 |
| 05:03:10 | | Quit prof_wolfff (Ping timeout: 246 seconds) |
| 05:10:49 | | Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods) |
| 05:11:42 | | Quit speachy (Quit: WeeChat 2.8) |
| 05:20:01 | | Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) |
| 05:49:50 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:00 |
| 06:38:38 | *** | Saving seen data "./dancer.seen" |
| 06:57:00 | | Quit kugel (Ping timeout: 256 seconds) |
| 06:58:25 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 07:00 |
| 07:04:22 | | Quit pamaury (Ping timeout: 272 seconds) |
| 07:18:54 | | Join speachy [0] (~speachy@209.2.65.77) |
| 07:20:02 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 07:26:34 | | Quit Stanley00 (Remote host closed the connection) |
| 07:28:30 | | Join Huntereb [0] (~Huntereb@174.226.11.80) |
| 07:32:05 | speachy | efqw: ok, I see the problem, guess that's why the code was commented out in the vortex tree. |
| 07:32:17 | speachy | and, ugh, poking through fiio's sources, they're bitbanging the i2c comms |
| 07:44:17 | fs-bluebot | Build Server message: New build round started. Revision 4873a1a, 291 builds, 9 clients. |
| 07:52:16 | speachy | efqw: when this one's done it will at least get past that panic. But I'm glad the launcher worked! |
| 07:59:30 | fs-bluebot | Build Server message: Build round completed after 912 seconds. |
| 07:59:33 | fs-bluebot | Build Server message: Revision 4873a1a result: All green |
| 08:00 |
| 08:06:59 | _bilgus_ | #g2845 framrbuffer rewrite appreciate any tesing anyone can do |
| 08:08:11 | mendel_munkis | _bilgus_: g#2845 or g#2811? |
| 08:08:14 | fs-bluebot | Gerrit review #2845 at http://gerrit.rockbox.org/r/2845 : Fix compile warnings (set-but-not-used) on big endian targets by Solomon Peachy |
| 08:08:15 | fs-bluebot | Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct WIP by William Wilgus |
| 08:08:24 | _bilgus_ | lol g#2811 |
| 08:08:25 | fs-bluebot | Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct WIP by William Wilgus |
| 08:09:39 | mendel_munkis | I a running a few other builds right now hopefully I will try it sometime this week. |
| 08:10:28 | _bilgus_ | I haev the testing down for quite a few players sitting here but I really need some 2 bit screens and some remotes |
| 08:10:50 | mendel_munkis | ah. my clip+ has a broknn screen so not much help there. |
| 08:10:54 | speachy | they expose something like 19 mixer controls, only three actually do anything on this hardware |
| 08:11:32 | speachy | _bilgus_: I think the ipodmini2g qualifies as 2bit? |
| 08:11:37 | _bilgus_ | On the road w/ me I now have a Clip+ zip fuzev2 x3 , Rocker |
| 08:11:58 | _bilgus_ | yeah one of those ipods has a reverse 2 bit screen |
| 08:12:43 | speachy | 2811 builds on 2415? |
| 08:13:35 | _bilgus_ | yeah mendel asked me to include his fb excise |
| 08:13:48 | _bilgus_ | (their*) |
| 08:14:19 | _bilgus_ | I figured the easiest way was just to make it parent |
| 08:14:20 | mendel_munkis | for the record I don't mind being referred to as he |
| 08:18:09 | _bilgus_ | the framebuffer code is (was?) a freaking mess hopefully this makes it better |
| 08:20:19 | speachy | anything in particular I should try? |
| 08:20:24 | speachy | (building now) |
| 08:29:13 | speachy | music playback with a spinning cube is good. |
| 08:35:46 | speachy | _bilgus_: seems to work with everything I've thrown at it so far |
| 08:37:11 | _bilgus_ | trouble areas are the core stuff that statusbar code is scary! |
| 08:37:35 | _bilgus_ | for the most part plugins should JUST WORK (tm) |
| 08:38:37 | speachy | yeah, I didn't see anything out of whack with the main statusbar. granted I was just using the stock cabbiev2 theme |
| 08:38:40 | *** | Saving seen data "./dancer.seen" |
| 08:39:37 | _bilgus_ | backdrops store the offset from the current veiwport buffer it was really hard to track across the code |
| 08:41:24 | _bilgus_ | I think even cabbie actually has quite a few viewports |
| 08:43:42 | speachy | but I'm not exactly a "power user" :D |
| 08:47:19 | _bilgus_ | I already found one bug viewport_set_fullscreen I moved the sizing to set_default which works because they most of the code calls both but still... |
| 08:47:35 | speachy | do you think this would have any effect on the occasional display artifact that happens when eg a splash notification leaves behind someting? |
| 08:51:37 | _bilgus_ | possibly but it should still be using the same underlying buffer so I don't think having too big a viewprt would do that |
| 08:52:38 | speachy | it's basically that the splash code expects the underlyng framebuffer to get completely repainted and (eg) the wps screen only repaints updates. |
| 08:52:43 | speachy | s/updates/regions/ |
| 08:53:36 | _bilgus_ | I imagine that would happen at head then |
| 08:53:39 | speachy | hmm. I wonder if there's any way to force a complet screen repaint |
| 08:53:47 | _bilgus_ | there is |
| 08:54:31 | _bilgus_ | the action system has redraw and there are force full update flags in the them engine too |
| 08:54:40 | _bilgus_ | theme* |
| 09:00 |
| 09:00:40 | speachy | the softlock/unlock action already fires off ACTION_REDRAW apparently |
| 09:01:11 | _bilgus_ | IIRC I had to do that to remove the messages |
| 09:01:49 | | Join p3tur [0] (~petur@77.77.179.66) |
| 09:01:49 | | Quit p3tur (Changing host) |
| 09:01:49 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
| 09:02:54 | speachy | I wonder if the problem is that the areas not getting repainted are the _background_ elements. |
| 09:05:20 | | Quit petur (Ping timeout: 272 seconds) |
| 09:08:54 | _bilgus_ | hmm and now the fuze+ sim is broken :/ |
| 09:09:13 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:18:29 | speachy | backdrop is not repainted under a full refresh. |
| 09:19:32 | _bilgus_ | does taht happen at head too or only after the patch? |
| 09:22:18 | speachy | I didn't check under the patch; this was definitely on head |
| 09:22:59 | speachy | I think I have a fix |
| 09:24:39 | speachy | yikes, on the x3ii display is quite busted |
| 09:25:17 | _bilgus_ | I know what destroyted the sim I had to move to a void pointer to allow the lcd/lcd_remote probably the smae thing |
| 09:25:35 | speachy | only the top 1/3 of the screen is dispalying anything |
| 09:25:48 | _bilgus_ | luckily I can test that! |
| 09:26:08 | _bilgus_ | hehe yeah moving to void* is throwing off the elem count |
| 09:26:23 | speachy | checking to see if the sim is busted the same way |
| 09:27:12 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 09:27:35 | speachy | quite broken, albeit different visually |
| 09:29:35 | _bilgus_ | and this is why we test lol |
| 09:32:03 | | Quit Stanley00 (Ping timeout: 260 seconds) |
| 09:38:49 | _bilgus_ | ok fixed |
| 09:41:37 | _bilgus_ | not sure how I didn't catch that I even checked it lol must have been 'lucky' |
| 09:52:11 | speachy | oh, there's also a race condition going on between the rocker/etc hotplug stuff I hooked up rockbox's own remount hooks. |
| 09:52:42 | speachy | if hotplug remounts things prior to rockbox getting to it, then rockbox will panic. |
| 09:53:08 | _bilgus_ | oh I bet thats the issue on unplug 'invalid control file' |
| 09:53:43 | speachy | possibly. haven't seen that in a while though. |
| 09:53:53 | _bilgus_ | that bug is so old every time I find something fkd I hope it fixes it lol |
| 09:54:18 | _bilgus_ | I found its dirty cousin a while back |
| 09:54:33 | speachy | I've fixed a ton of stuff that could have led to it |
| 09:57:21 | | Nick p3tur is now known as petur (~petur@rockbox/developer/petur) |
| 10:00 |
| 10:00:12 | _bilgus_ | ok latest patch is up x3 works now along with the sims |
| 10:02:49 | braewoods | it's amusing. the h1x0 series... the most common variant is the h120 |
| 10:03:11 | braewoods | i can't practically test the h100 bootloader simply because i can't find any units |
| 10:03:13 | braewoods | lol |
| 10:03:46 | braewoods | but they're sister units so... if the h120 works, they should both work... main differences are the RAM and storage. |
| 10:03:53 | _bilgus_ | we run into that issue a lot braewoods |
| 10:04:08 | braewoods | i ee. |
| 10:04:10 | braewoods | see |
| 10:04:34 | _bilgus_ | also totally appreciate if you could test g#2811 |
| 10:04:36 | fs-bluebot | Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct WIP by William Wilgus |
| 10:04:40 | _bilgus_ | on that remote screen |
| 10:04:47 | braewoods | sometime this week |
| 10:05:25 | _bilgus_ | no hurry I still have to clean up & try to optimize |
| 10:05:56 | braewoods | i'll eventually try to build an official V7 bootloader for the H120/H140 |
| 10:06:08 | braewoods | i'm hestitant to do the same for H100 since i can't test it |
| 10:06:58 | braewoods | i'll see if the community has anyone that can help |
| 10:07:05 | _bilgus_ | yeah especially if they are difficult to recover |
| 10:07:18 | braewoods | the H120, i can just buy a junker to test with |
| 10:07:24 | braewoods | if it bricks it, so what? plenty more on ebay |
| 10:07:28 | _bilgus_ | geaverts has a tower of rockbox unrivaled |
| 10:08:01 | braewoods | gevaerts: you own any iriver h100 units? the h110, h115, etc? |
| 10:08:06 | _bilgus_ | saying for the end user we don't want to break anyones baby |
| 10:08:51 | braewoods | the iriver h1x0 and h3x0 are riskier but i like their approach more |
| 10:09:13 | braewoods | i think i will try to publish new bootloaders for the h3x0 series at some point |
| 10:09:27 | braewoods | but later |
| 10:10:02 | braewoods | i don't want to push something out unless i'm fairly certain it actually works |
| 10:10:04 | braewoods | :) |
| 10:10:10 | _bilgus_ | now the fun part lets see how much my address translation slows down the lcd |
| 10:16:47 | _bilgus_ | nice on the x3 its within measurement error < 5% |
| 10:16:58 | speachy | but that's a pretty overpowered target |
| 10:17:03 | _bilgus_ | some went up some went down |
| 10:17:15 | _bilgus_ | yeah I'll be testing the zip next |
| 10:17:16 | speachy | even with the impact IMO this is worth it |
| 10:17:37 | _bilgus_ | agreed but i'll try to minimize it if at all possible |
| 10:21:11 | _bilgus_ | I really don't like passing that void* around and having to cast every where but I think the alternative is going to make it more complicated |
| 10:21:39 | braewoods | _bilgus_: why is it cast? |
| 10:21:41 | braewoods | or void* |
| 10:21:51 | braewoods | i usually see that used because |
| 10:22:00 | braewoods | you need to take variable types |
| 10:22:11 | braewoods | due to C lacking union types |
| 10:22:16 | braewoods | or derived types even |
| 10:22:17 | _bilgus_ | remote lcd has a (usually) different data size for the frame buffer |
| 10:22:55 | _bilgus_ | the address function has to handle both so it needs to be void* and then cast |
| 10:23:03 | braewoods | _bilgus_: meaning the underlying data is a different type or just different sized array? |
| 10:23:19 | _bilgus_ | both |
| 10:23:23 | braewoods | I see. |
| 10:23:34 | braewoods | if it helps you can try using type punning |
| 10:23:38 | braewoods | about the only alternative |
| 10:23:52 | braewoods | i've seen people use that instead of void* |
| 10:24:00 | braewoods | and somehow know which type is in use in any given usage |
| 10:24:59 | braewoods | if our toolchains were C11 capable... |
| 10:25:12 | braewoods | could use type punning with _Generic to set it automatically on the caller's side |
| 10:25:23 | braewoods | via macros |
| 10:25:25 | braewoods | thank you CPP |
| 10:25:48 | _bilgus_ | I'll keep my C thanks :p |
| 10:26:17 | braewoods | _bilgus_: well it's one thing i thought of but i believe gcc 4.9.x doesn't have _Generic yet |
| 10:26:27 | * | braewoods shrugs |
| 10:26:36 | braewoods | anyway |
| 10:26:53 | _bilgus_ | so If I put in a union for the data field that would get rid of some of it |
| 10:27:06 | braewoods | yea... |
| 10:27:19 | braewoods | it's useful but requires extra work |
| 10:27:30 | braewoods | some of it can be automated with modern C11 stuff |
| 10:27:35 | braewoods | _Generic is rather useful |
| 10:27:43 | braewoods | you can automatically choose a type enum with it |
| 10:27:54 | braewoods | so it has no runtime overhead, the setup anyway |
| 10:28:01 | braewoods | you still have runtime overhead for checking it if you choose to do so |
| 10:28:15 | fs-bluebot | Build Server message: New build round started. Revision d544ce4, 291 builds, 9 clients. |
| 10:28:16 | braewoods | but void* has no such way to check it |
| 10:28:20 | braewoods | you just assume |
| 10:28:33 | braewoods | this has some manual type checking |
| 10:28:38 | braewoods | made possible at runtime |
| 10:29:14 | speachy | ok, that should solve the mount-already-happened panic. |
| 10:29:51 | speachy | and the m3k is completely dependent on hotplug to do the remounting |
| 10:30:53 | _bilgus_ | yes definitely a fan of builtin error checking |
| 10:32:00 | _bilgus_ | I need to fire up my pc next time i'm home and leave it up to do builds for me clean builds take sooo long |
| 10:36:18 | _bilgus_ | speachy hotplug as in a service running on the base OS? |
| 10:36:24 | speachy | yeah |
| 10:38:43 | *** | Saving seen data "./dancer.seen" |
| 10:39:25 | speachy | _bilgus_: good news, x3ii display works now. until I segfaulted the oscilloscope plugin (also a bug with HEAD) |
| 10:39:56 | _bilgus_ | that damn o-scope |
| 10:40:10 | _bilgus_ | great! |
| 10:40:14 | speachy | more like damn hosted target issues |
| 10:40:45 | _bilgus_ | I figured it was the last bug I fixed in it re appearing |
| 10:41:27 | speachy | I get some visual corruption in the FFT demo too when switching modes |
| 10:42:01 | | Quit massiveH (Quit: Leaving) |
| 10:42:32 | speachy | looks almost like a picture-in-picture going on; a default viewport is being initiaalized that doesn't respect the screen properly. it does self-correct. |
| 10:43:12 | speachy | wait, it's like it tries to render stuff in the statusbar. |
| 10:45:48 | fs-bluebot | Build Server message: Build round completed after 1053 seconds. |
| 10:45:49 | fs-bluebot | Build Server message: Revision d544ce4 result: All green |
| 10:51:12 | gevaerts | braewoods: no. I have a h120 somewhere I think, but I don't know what state it's in, really. No 100 or 110 |
| 10:51:19 | braewoods | ok. |
| 10:51:23 | braewoods | i thought as much. |
| 10:51:48 | braewoods | i'll see if i can find anyone to help test a new bootloader though that unit is very rare from what i've seen |
| 10:51:56 | braewoods | the h120 is the most common to see pop up |
| 10:51:59 | braewoods | same with h320 |
| 10:53:00 | _bilgus_ | speachy do you still get the statusbar while running fft? |
| 10:53:30 | speachy | no, it's .. maybe 20 pixels high and 100 pixels wide in the upper-left corner |
| 10:53:35 | speachy | the area of interest |
| 10:54:05 | _bilgus_ | weird not seeing it on the x3 |
| 10:54:12 | _bilgus_ | i'll try the clipzip |
| 10:54:42 | speachy | rocker is probably a better one to try |
| 10:55:28 | _bilgus_ | plugins get their viewprot based on whatever is default when they start |
| 10:55:37 | _bilgus_ | viewport* |
| 10:55:39 | speachy | I don't recall seeing it before but I don't reember if I ever launched this before on the x3ii |
| 10:56:28 | _bilgus_ | so maybe the better idea would be to have it explicitly set it up and use that as the default for people that want to access directly |
| 10:56:49 | _bilgus_ | I already added explicit cleanup on plugin_exit |
| 10:57:45 | | Quit pamaury (Ping timeout: 265 seconds) |
| 10:58:05 | speachy | when you switch modes, you'll see the full fft going on-screen, but in that corner thre's a sorta-mini-fft being rendered |
| 10:58:13 | speachy | it goes away after a second or two |
| 10:58:18 | _bilgus_ | my guess* is its probably getting remnants of the sb viewport |
| 10:59:41 | _bilgus_ | speachy if you change the sb position to bottom does it move to the lower corner? |
| 10:59:55 | _bilgus_ | settings>themes>sb |
| 11:00 |
| 11:01:15 | speachy | no change |
| 11:01:47 | speachy | but! there's also a central corruption too, and it's due to the splash text |
| 11:02:13 | _bilgus_ | hmm, I also have something weird showing up in the fps test plugin too sounds like I still have a bit of work yet |
| 11:03:14 | speachy | ooo. |
| 11:03:22 | speachy | yeah, it's related to the splash text. |
| 11:03:48 | speachy | it's the same size/dimensions as the splash text, same garbage in both |
| 11:05:06 | _bilgus_ | FFS i'm testing on head! |
| 11:05:39 | _bilgus_ | so the testfps plugin is broken on the clipzip at head |
| 11:06:09 | _bilgus_ | makes me wonder when that happened |
| 11:06:55 | speachy | oh, new toolchain or old toolchain? |
| 11:06:58 | speachy | might matter |
| 11:07:17 | _bilgus_ | old |
| 11:07:21 | speachy | nevermind then |
| 11:07:40 | _bilgus_ | I figured i'll upgrade once my tree is empty again |
| 11:07:41 | speachy | havne't managed to figure out where in the theme/skin code one forces the background to get repainted |
| 11:15:46 | _bilgus_ | it uses a switch in lcd_clearviewport |
| 11:16:21 | _bilgus_ | lcd-16bit-common |
| 11:20:01 | _bilgus_ | what I found off was that it switches to the default fb to do screen clear and then switches back |
| 11:20:03 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 11:20:08 | _bilgus_ | odd not off |
| 11:25:15 | | Quit petur (Quit: Connection reset by beer) |
| 11:26:46 | _bilgus_ | ok so splash sets its own vp and then restores the default instead of the one inflight |
| 11:26:46 | _bilgus_ | <_bilgus_> maybe set_vp should return the current one |
| 11:28:25 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 11:33:31 | | Quit Stanley00 (Ping timeout: 265 seconds) |
| 11:46:47 | speachy | well.. it's leaving behind part of the splash |
| 11:47:27 | speachy | the "full repaint" that the wps is triggering isn't restoring the background over that area |
| 11:47:42 | speachy | even when I force the wps to repaint all lines |
| 11:50:54 | _bilgus_ | thats because it should be restoring the theme buffer but its restoring default |
| 11:51:40 | _bilgus_ | worked before because the fb doesn't get changed when you set the default |
| 11:51:48 | _bilgus_ | now it does |
| 11:53:48 | _bilgus_ | now If I can only figure out who has it defined as returning void probably an extern somewhere |
| 11:54:45 | _bilgus_ | great now I need to hunt for all users of this in core and change accordingly |
| 11:55:02 | speachy | just remember, you're doing this for fun! |
| 11:58:47 | _bilgus_ | it is fun and itll be even more fun when I get to revisit luas image code |
| 11:58:59 | _bilgus_ | or thats what I'll tell myself |
| 12:00 |
| 12:38:47 | *** | Saving seen data "./dancer.seen" |
| 12:47:04 | _bilgus_ | nice I think that should resolve the rest of the issues there were a couple spots that I wasn't totally sure what the intent was so I left them be as restoring default_vp one was the eq screen but it appears to work properly |
| 12:47:59 | _bilgus_ | and agter removing the giant block of color in test_fps its within 1% of the readings I could see at HEAD |
| 12:48:03 | _bilgus_ | after* |
| 12:48:09 | | Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:95e7:97d6:1fb5:7a52) |
| 12:56:32 | | Quit MrZeus (Read error: No route to host) |
| 12:58:05 | | Join MrZeus [0] (~MrZeus@90.203.212.4) |
| 13:00 |
| 13:01:40 | _bilgus_ | plugins still do the same probably a similar situation |
| 13:17:53 | _bilgus_ | the plugins taht have an issue all seem to use the OSD plugin lib |
| 13:18:46 | speachy | ugh. looks like the de-emphasis filter on the X3 should be disabled by default. |
| 13:19:28 | speachy | would be nice to make it an option. |
| 13:20:08 | | Quit pamaury (Ping timeout: 260 seconds) |
| 13:20:55 | | Quit Huntereb (Read error: Connection reset by peer) |
| 13:25:58 | | Quit pixelma (Quit: .) |
| 13:25:58 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 13:28:32 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 13:28:33 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 13:29:07 | efqw | speachy: tried this one http://download.rockbox.org/daily/fiiom3k/rockbox-fiiom3k.zip and I can see the launcher now |
| 13:29:20 | efqw | Still getting the same panic if I launch rb though |
| 13:29:34 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 13:29:38 | speachy | you'll need the latest dev build |
| 13:30:05 | speachy | ie newer than the last nightly |
| 13:31:12 | efqw | where are those builds located? |
| 13:32:13 | speachy | https://build.rockbox.org/data/rockbox-fiiom3k.zip |
| 13:32:27 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 13:32:29 | speachy | not on the builds page as there's no way to actually look at them yet. |
| 13:33:58 | fs-bluebot | Build Server message: New build round started. Revision 0cde20f, 291 builds, 9 clients. |
| 13:34:30 | | Quit Stanley00 (Ping timeout: 272 seconds) |
| 13:35:49 | efqw | https://www.irccloud.com/pastebin/zUvFkWbb/ |
| 13:35:58 | efqw | getting a lot of spam in the console :P |
| 13:37:02 | efqw | Oh, and [ 109.744900] graphics fb0: Unknown ioctl 0x0 when the screen turns on |
| 13:37:04 | speachy | efqw: that's from the of, not rockbox |
| 13:37:25 | efqw | [ 131.483810] graphics fb0: Unknown ioctl 0x4 when the screen turns off |
| 13:37:37 | speachy | the ioctl is probably our doing. |
| 13:39:15 | _bilgus_ | OK I got it narrowed down to the code in OSC that attempts to restore the original framebuffer data with bitmap_part |
| 13:39:40 | _bilgus_ | _osd_erase_osd |
| 13:39:46 | _bilgus_ | same with the fft plugin |
| 13:40:07 | _bilgus_ | and probably anyone else using OSD |
| 13:41:08 | efqw | I'll have to grep from init.d to find what exactly is doing this rmmod thing |
| 13:41:13 | speachy | that probably explains the segfaults that crop up on plugins on hosted targets |
| 13:43:10 | _bilgus_ | quite possible< there is a bounds issue or just failure to set the data |
| 13:43:37 | efqw | Pressing the power button doesn't seem to turn off the screen. |
| 13:44:00 | efqw | It can turn on the screen after the backlight times out, but not the other way |
| 13:44:30 | speachy | efqw: as in the only mention of that module is in a commented-out init script, and the OF player binary |
| 13:44:47 | braewoods | ok. |
| 13:44:48 | speachy | so you're inside rockbox? |
| 13:44:50 | _bilgus_ | I don't remember us having that feature s that something extended from the OF efqw? |
| 13:44:52 | efqw | yes |
| 13:44:53 | braewoods | i posted about the new bootloaders. |
| 13:45:00 | braewoods | hopefully i'll get some community testing. |
| 13:45:03 | braewoods | https://forums.rockbox.org/index.php/topic,53611.0.html |
| 13:45:12 | efqw | but the player binary isn't actually running |
| 13:45:27 | efqw | so technically we shouldn't get the rmmod spam |
| 13:45:49 | efqw | I killed everything that is not a kernel process (other than rb) and it's still doing it |
| 13:47:16 | _bilgus_ | braewoods, Pinned your topic |
| 13:47:23 | braewoods | _bilgus_: thanks |
| 13:47:25 | speachy | efqw: ok, found the offending bit. |
| 13:47:37 | speachy | (a serious wtf in the vortex code) |
| 13:47:58 | efqw | lol |
| 13:48:25 | fs-bluebot | Build Server message: Build round completed after 868 seconds. |
| 13:48:27 | fs-bluebot | Build Server message: Revision 0cde20f result: All green |
| 13:48:28 | fs-bluebot | Build Server message: New build round started. Revision 455a23b, 291 builds, 9 clients. |
| 13:49:07 | efqw | I'll stay on for a couple of hours from now so we could hopefully get some testing done. |
| 13:49:43 | efqw | Should we remove the adb stuff from the launcher? |
| 13:49:46 | speachy | efqw: building a fix. |
| 13:49:49 | efqw | It's not like it's doing anything |
| 13:50:05 | speachy | efqw: eventually, yes, but due to how the menu is implemented it's a PITA |
| 13:50:19 | speachy | efqw: I'm still holding out hope of being able to actually use adb though |
| 13:50:21 | * | efqw nods |
| 13:50:56 | speachy | I figure that until we can come up with a non-flastool method of getting the launcher onto the m3k, there's no rush to polish it. |
| 13:51:34 | efqw | Oh, and shutdown doesn't work |
| 13:51:43 | efqw | https://www.irccloud.com/pastebin/Hd6HqsLD/ |
| 13:52:00 | efqw | this happens if I hold the power button to tell rb to shut down the machine |
| 13:52:06 | speachy | efqw: http://www.shaftnet.org/~pizza/m3k-test.zip |
| 13:52:11 | efqw | same happens if I do `shutdown` in the console |
| 13:52:38 | _bilgus_ | lol and yet you still went there! |
| 13:52:50 | efqw | look at the timestamps of the messages, the UART Rx indicator lights up _solid_ |
| 13:55:04 | speachy | this port is such a hacky mess. |
| 13:55:43 | efqw | well, at least we have the source now, so it's possible to clean it up gradually at a bare minimum |
| 13:55:45 | speachy | efqw: does a short press on the power button activate the soft lock, at least? |
| 13:56:39 | efqw | Console spam is gone. |
| 13:57:01 | efqw | And no, it does not activate soft lock. The touch panel is fully responsive |
| 13:58:43 | efqw | Well, not *all* of the rmmod stuff is gone, but at least it's not spamming the console anymore. |
| 13:58:48 | speachy | but it wakes the screen up, huh. ok, probably a broken keymapping. |
| 13:58:57 | efqw | https://www.irccloud.com/pastebin/JjRD3390/ |
| 13:59:23 | efqw | There is still a little bit of it during the startup process |
| 14:00 |
| 14:00:12 | speachy | ok, that's probably in the launcher code. |
| 14:00:25 | speachy | (I'll have to rebuilt it) |
| 14:00:36 | efqw | The hamburger menu button on the touch panel seems to be mapped to play/pause, when I touch it the player says "nothing to resume" |
| 14:01:05 | efqw | The hardware play/pause button doesn't do this however, it's equivalent to "confirm" in the menu. |
| 14:01:46 | speachy | I didn't muck with this stuff at all |
| 14:02:21 | efqw | Whenever I press the volume buttons, the vol indicator on top of the screen disappears for 1s and then comes back. |
| 14:04:07 | | Quit Rower (Ping timeout: 258 seconds) |
| 14:05:22 | speachy | ok, the ioctl errors are from the screen blank/unblank code. it seems FB driver doesn't actually respond to standard commands. WTF. |
| 14:06:38 | speachy | efqw: do you have /sys/class/lcd on there? |
| 14:07:10 | efqw | Yup, I have /sys/class/lcd/truly_tft240240_slcd |
| 14:07:42 | speachy | echo "4" > /sys/class/lcd/truly_tft240240_slcd/lcd_power |
| 14:07:49 | speachy | should turn it off |
| 14:08:02 | speachy | echo "0" > /sys/class/lcd/truly_tft240240_slcd/lcd_power (back on) |
| 14:09:05 | efqw | Nothing happens unfortunately. |
| 14:09:09 | speachy | ok. |
| 14:09:38 | speachy | (one more hacky lie..) |
| 14:09:47 | * | efqw shakes head |
| 14:09:58 | speachy | does audio playback work? |
| 14:10:15 | efqw | I haven't tried, I'll get another MicroSD and dig up some music |
| 14:10:24 | speachy | no worries. |
| 14:10:36 | speachy | ok, one thing I'd like you to do. |
| 14:11:09 | efqw | as you can tell the card I'm using is an ancient crap that can barely sustain 1MB/s sequential writes |
| 14:11:26 | speachy | http://www.shaftnet.org/~pizza/m3k-test2.zip |
| 14:11:30 | efqw | copying music to this would be a huge pain |
| 14:12:50 | braewoods | efqw: ouch. my CF modded RBs can normally do around 10 |
| 14:13:01 | braewoods | my H10 being an odd exception |
| 14:13:53 | speachy | cat /dev/input/event* | hexdump -C |
| 14:14:02 | speachy | hit each key one by one |
| 14:14:25 | fs-bluebot | Build Server message: Build round completed after 1557 seconds. |
| 14:14:26 | fs-bluebot | Build Server message: Revision 455a23b result: All green |
| 14:14:31 | speachy | (please keep track of the order so we know what each one corresponds to) |
| 14:16:28 | efqw | Hardware buttons do not show up at all. |
| 14:17:40 | speachy | ok, try that again with /dev/input/event1 (vs event0) |
| 14:20:19 | efqw | Works. I'll go grab something to eat and compose a table soon. |
| 14:33:28 | fs-bluebot | Build Server message: New build round started. Revision 2e07223, 291 builds, 9 clients. |
| 14:38:49 | *** | Saving seen data "./dancer.seen" |
| 14:46:16 | _bilgus_ | SPEACHY! https://github.com/jz47xx/jz47xx.github.io/tree/master/manuals |
| 14:48:17 | | Join johnb7 [0] (~johnb2@p5b3af21a.dip0.t-ipconnect.de) |
| 14:49:15 | fs-bluebot | Build Server message: Build round completed after 946 seconds. |
| 14:49:18 | fs-bluebot | Build Server message: Revision 2e07223 result: All green |
| 14:51:51 | _bilgus_ | nope nm still doesn't have the UI one |
| 14:52:09 | speachy | _bilgus_: good find, but I think we already have all of that stuff |
| 14:52:15 | speachy | (except perhaps the 4770 stuff) |
| 14:52:46 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 14:53:27 | _bilgus_ | came through the forum |
| 14:53:50 | speachy | cloning it all just in case |
| 14:55:15 | _bilgus_ | same lol |
| 14:55:41 | speachy | what's another 800M of disk space |
| 14:56:50 | efqw | audio playback works great |
| 14:57:01 | speachy | hmm. it's probably safe to nuke the pre-migration rockbox snapshots. |
| 14:57:22 | _bilgus_ | I wonder how closly the 70 series ui manual matches the 60's |
| 14:57:25 | efqw | only tried flac but I assume if flac works everything else should work too? |
| 14:57:43 | _bilgus_ | those 4770 manulas are something I haven't seen before |
| 14:57:58 | _bilgus_ | efqw a faulty assumption.. |
| 14:58:00 | speachy | volume control? |
| 14:58:30 | efqw | volume control works just fine |
| 15:00 |
| 15:01:11 | efqw | Softlock works in test-2.zip |
| 15:01:28 | speachy | efqw: well, that's not from anything I changed! |
| 15:02:31 | efqw | 😂 |
| 15:05:31 | lebellium | braewoods: "only" €99 :) https://www.ebay.fr/itm/iRiver-iHP-100-10GB-MP3-FLAC-ROCKBOX-Player/164441914770?hash=item2649807d92:g:OGgAAOSwMU5fVSK1 |
| 15:05:42 | braewoods | talk about rare |
| 15:06:02 | speachy | it has the rockbox tax pre-applied |
| 15:06:56 | braewoods | lol |
| 15:09:03 | braewoods | that didn't show up in my searches |
| 15:09:06 | braewoods | not surprising i guess |
| 15:09:57 | efqw | https://www.irccloud.com/pastebin/AmIYa9oh/ |
| 15:10:13 | efqw | hw buttons done |
| 15:11:01 | lebellium | BTW, aside the store capacity, what's the difference between the H100/H115 and H120/H140? I never understood why those are 2 different Rockbox targets with separated builds |
| 15:11:21 | braewoods | lebellium: RAM. |
| 15:11:27 | braewoods | H100 has 16MB |
| 15:11:32 | braewoods | H120 has 32MB |
| 15:11:36 | braewoods | so they have to be different |
| 15:12:06 | braewoods | the H3x0 devices apparently all have the same RAM |
| 15:12:29 | braewoods | though i must say i love the H120 series |
| 15:12:38 | braewoods | they're very featureful |
| 15:12:39 | lebellium | ah interesting |
| 15:12:44 | braewoods | and... |
| 15:12:49 | braewoods | one of the better rockbox ports |
| 15:12:54 | _bilgus_ | ok so what is going on with OSD is that it is copying from the same buffer for the clear so it needs to tak into account the direction |
| 15:13:14 | braewoods | i can actually load rockbox into ROM with the iriver h1x0 |
| 15:13:21 | braewoods | something i didn't know was possible lol |
| 15:13:40 | lebellium | Yes I like my H140 too although I never use it like pretty much all my DAPs :D |
| 15:15:41 | lebellium | I tried the optical out with my AV receiver optical in but it seems that the red light is not powerful enough, my receiver doesn't get the signal. I don't know if the optical out gets weaker over time or if it was an iriver design fault |
| 15:17:01 | _bilgus_ | lebellium, might try a different interconnect I know the yamaha ones I got were glass but Ive seen some lower quality ones that look to be fishing line |
| 15:20:51 | | Join pixelma_ [0] (marianne@rockbox/staff/pixelma) |
| 15:20:52 | | Quit pixelma (Killed (wolfe.freenode.net (Nickname regained by services))) |
| 15:20:52 | | Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) |
| 15:20:55 | | Quit amiconn (Ping timeout: 240 seconds) |
| 15:21:03 | | Join amiconn_ [0] (jens@rockbox/developer/amiconn) |
| 15:21:04 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
| 15:21:58 | efqw | https://www.irccloud.com/pastebin/vH6tCamo/ |
| 15:22:16 | efqw | speachy: this is the soft buttons sans the scrolling stuff |
| 15:22:37 | efqw | I'll put the scrolling stuff in a separate paste |
| 15:30:37 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 15:31:36 | efqw | https://www.irccloud.com/pastebin/If8nkEuH/ |
| 15:32:26 | efqw | ok, this should cover all of the cases |
| 15:35:37 | | Quit Stanley00 (Ping timeout: 264 seconds) |
| 15:41:28 | | Quit johnb7 (Ping timeout: 265 seconds) |
| 15:45:06 | braewoods | i think next month i will try to acquire an iriver h320 to test an updated bootloader for as well |
| 15:45:38 | braewoods | would be nice to do all 3 but... |
| 15:45:50 | braewoods | the hardest to find unit is the h100 |
| 15:53:02 | braewoods | speachy: is rbutil capable of using HTTPS? |
| 15:53:40 | speachy | there are some issues with (I think) v1.4.0 |
| 15:54:10 | braewoods | i'm asking because i would like to update it in git to use https to download files |
| 15:54:16 | braewoods | for greater confidence in their integrity |
| 15:54:38 | braewoods | the website appears to have no issue with it |
| 15:54:38 | speachy | that's bluebrother's purview |
| 15:55:07 | braewoods | so only obvious problem is whether SSL is supported in rbutil |
| 15:57:24 | braewoods | bluebrother: what're your thoughts? i was hoping to update rbutil to use HTTPS by default in newer releases. |
| 15:58:01 | braewoods | it appears to be a simple set of changes is all that are needed |
| 16:00 |
| 16:00:16 | bluebrother | braewoods: the problem with https isn't Rockbox Utility, it's Qt. Qt itself can do ssl, but for older buikds it was disabled. That includes 1.4.0. |
| 16:00:47 | braewoods | bluebrother: so what's the harm in enabling it in newer ones? |
| 16:00:51 | braewoods | the older ones continue to work, no? |
| 16:00:59 | bluebrother | I actually wanted to enable ssl, after bringing everything up to date and before making the next release. |
| 16:01:11 | braewoods | Ok. i'll leave it be then. |
| 16:02:15 | bluebrother | well, if you change the urls in rbutil.ini there is no problem for older binaries. But the webserver forcing ssl breaks them. |
| 16:03:26 | braewoods | bluebrother: ah. i wasn't going for that. |
| 16:03:26 | bluebrother | we had a discussion about ssl some years ago The main thing is that Qt uses Openssl, which uses a different license. Since we wanted to have an all-in-one binary on Windows this caused some concerns w/ licensing. |
| 16:03:58 | braewoods | actually |
| 16:04:04 | braewoods | openssl's license changed awhile ago. |
| 16:04:20 | braewoods | not sure if it matters for that |
| 16:04:29 | braewoods | https://wiki.openssl.org/index.php/License |
| 16:04:30 | bluebrother | some dev binaries I made already have Qt w/ openssl linked. That was mainly because I used mxe to build them and didn't realize that :) |
| 16:04:32 | braewoods | or is in the process |
| 16:04:39 | braewoods | apache 2 license? apparently |
| 16:04:54 | braewoods | is that GPL incompatible? |
| 16:04:57 | braewoods | i'm not sure honestly |
| 16:05:42 | bluebrother | with the changes I want to make wrt bootloader installation we won't have a single binary anymore, so we can as well dynamically link, leaving those issues aside. |
| 16:05:55 | speachy | well, RB is GPLv2+, and GPLv3 is ASL2 compatible, so it is technically kosher. :D |
| 16:06:18 | bluebrother | and I'm not sure if those concerns would actually turn out to be a oroblem. We're oss anyway. |
| 16:06:25 | braewoods | Ah. |
| 16:06:31 | braewoods | in 2018 openssl was completely switched to |
| 16:06:33 | braewoods | apache |
| 16:06:53 | bluebrother | back when we had that discussion openssl wasn't ASL. |
| 16:06:59 | braewoods | i see that |
| 16:07:18 | bluebrother | so I guess that isn't an issue anymore. |
| 16:08:27 | braewoods | speachy: eventually i intend to make some bootloaders that we'll try to finalize as version 7 for the iriver h100, h120, h320 series |
| 16:08:38 | braewoods | pretty sure h320 also has issues with CF cards that is fixed in git |
| 16:08:48 | speachy | yep, it's the same basic platform |
| 16:09:10 | bluebrother | The missing ssl support basically stems from the goal to have a static binary on Windows, and for that I ended up building Qt myself.. And that disabled ssl support, and since ssl waasn't really used back then (like 10 years ago) nobody noticed / bothered. |
| 16:11:16 | bluebrother | btw, the ipod 5.5g came as 32M and 64M variant. At some point a way was found to determine the RAM size during runtime and those were merged. Maybe something similar could be done for h100 / h120. Though afaiu they'd still need different bootloaders. |
| 16:14:13 | efqw | Long pressing the power button opens the pandora's box |
| 16:14:53 | efqw | rb panicked with "Cannot get control 'DACL Playback Volume' info" |
| 16:17:44 | speachy | sounds like I need to bite the bullet and set up the cloner tool (and disassemble it so I can get a serial console) |
| 16:18:52 | efqw | I mean the cloner should be sufficient |
| 16:19:08 | efqw | You can load the serial gadget module and get a console over USB |
| 16:19:23 | efqw | That should be good enough for most use cases anyway |
| 16:32:10 | speachy | bluebrother, I'm wanting to add the Eros Q/K (and clones) to rbutil, but in a way that preserves the appropriate OF for each OEM. Unfortunately so far it looks like they share the same USB VID+PID, possibly differing only in the descriptor strings. |
| 16:32:28 | speachy | can rbutil match on those, or is it vid/pid only? |
| 16:35:09 | braewoods | speachy: should be viable... i know the linux kernel has all sorts of ways to match hardware specific workarounds or quirks to specific platforms |
| 16:37:18 | _bilgus_ | but does windows? |
| 16:37:24 | braewoods | no idea. |
| 16:37:36 | braewoods | i know you can probe information from /sys |
| 16:37:38 | braewoods | for Linux |
| 16:37:44 | speachy | I mean, libusb will do that for us just fine, the question is what rbutil currently supports |
| 16:38:14 | braewoods | if it doesn't we can probably add it |
| 16:38:33 | braewoods | the question i start from is whether the underlying layers support it... |
| 16:38:52 | *** | Saving seen data "./dancer.seen" |
| 16:39:24 | speachy | just don't want to reinvent a wheel that's already there. |
| 16:39:38 | speachy | (and greatly preferring to not touch C++) |
| 16:40:25 | braewoods | (void) cpp; |
| 16:40:27 | braewoods | lol |
| 16:58:39 | braewoods | _bilgus_: remote lcd works. what did you want done? |
| 16:59:29 | _bilgus_ | just fire it up, see if it displays properly on top of 2811 |
| 16:59:44 | _bilgus_ | assuming it works properly at head.. |
| 17:00 |
| 17:00:38 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 17:01:15 | braewoods | 2811? |
| 17:01:22 | _bilgus_ | g#2811 |
| 17:01:24 | fs-bluebot | Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct WIP by William Wilgus |
| 17:02:59 | braewoods | _bilgus_: are you sure this is for the h100 / h120 series? |
| 17:03:06 | braewoods | _bilgus_: i only see h300 modified |
| 17:03:29 | fs-bluebot | Build Server message: New build round started. Revision df8b817, 291 builds, 9 clients. |
| 17:03:49 | _bilgus_ | its linked in core those players were just ones using lcd_identifiers they had no business touching |
| 17:04:13 | _bilgus_ | probably as an 'optimization' |
| 17:04:20 | braewoods | how do i build from this? |
| 17:04:27 | braewoods | or is there a build already? |
| 17:05:10 | _bilgus_ | no builds |
| 17:05:46 | _bilgus_ | see the guilde to compiling for hints to do it from patches or you can do it with git-review |
| 17:06:46 | _bilgus_ | if you don't have git-review apt-install and thenm git-review -d I0d04c3834e464eca84a5a715743a297a0cefd0af |
| 17:07:45 | mendel_munkis | huh. android ndk no longer works without clang. this may be why I was having build issues. |
| 17:08:11 | _bilgus_ | itll pull in as william/wilgus.... then create device folder cd into it do ../tools/configure pick device and press 'n' make && make zip |
| 17:09:11 | braewoods | have to build a new toolchain first |
| 17:09:46 | _bilgus_ | thatll be a bit go ahead with that but i'll put up a build for you |
| 17:11:54 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
| 17:11:57 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 17:12:29 | speachy | _all_ of the Eros-Q/K series and clones share the same USB VID/PID. Ditto for the xDuoo X3ii and X20. |
| 17:12:43 | speachy | which is bad, because the latter definitely is _not_ compatible |
| 17:14:35 | _bilgus_ | call the china USB id ? |
| 17:15:31 | speachy | also the AGPTek H3 cannot share the same update image as the other Eros clones. |
| 17:15:52 | speachy | (Artificial restriction; they changed the model string that's checked against) |
| 17:16:06 | lebellium | I should get mine in a few days btw |
| 17:17:17 | fs-bluebot | Build Server message: Build round completed after 829 seconds. |
| 17:17:23 | fs-bluebot | Build Server message: Revision df8b817 result: All green |
| 17:30:56 | _bilgus_ | braewoods, http://www.mediafire.com/folder/gtebq7pdz9bhw/iRiverh100 |
| 17:31:39 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 17:31:55 | _bilgus_ | there is still a bug in the OSD code but it should work fine besides a bit of garbage on update |
| 17:34:31 | fs-bluebot | Build Server message: New build round started. Revision 1a76bc4, 291 builds, 10 clients. |
| 17:36:26 | | Quit Stanley00 (Ping timeout: 272 seconds) |
| 17:39:07 | | Quit lebellium (Quit: Leaving) |
| 17:47:45 | fs-bluebot | Build Server message: Build round completed after 794 seconds. |
| 17:47:46 | fs-bluebot | Build Server message: Revision 1a76bc4 result: All green |
| 17:55:25 | | Quit pamaury (Ping timeout: 264 seconds) |
| 18:00 |
| 18:35:07 | | Quit _bilgus_ (Ping timeout: 260 seconds) |
| 18:37:02 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:8880:3cbe:369:d070) |
| 18:38:54 | *** | Saving seen data "./dancer.seen" |
| 18:46:25 | | Quit _bilgus (Ping timeout: 240 seconds) |
| 18:51:11 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:8880:3cbe:369:d070) |
| 19:00 |
| 19:28:46 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 19:33:28 | | Quit Stanley00 (Ping timeout: 260 seconds) |
| 19:47:46 | | Join fs-bluebot_ [0] (~fs-bluebo@55d455f2.access.ecotel.net) |
| 19:48:02 | | Quit bluebrother (Disconnected by services) |
| 19:48:07 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 19:50:10 | | Quit fs-bluebot (Ping timeout: 256 seconds) |
| 20:00 |
| 20:10:01 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 20:10:12 | | Quit _bilgus (Ping timeout: 260 seconds) |
| 20:10:22 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:8880:3cbe:369:d070) |
| 20:14:55 | | Quit _bilgus (Ping timeout: 240 seconds) |
| 20:15:02 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:8880:3cbe:369:d070) |
| 20:20:07 | | Quit _bilgus (Ping timeout: 260 seconds) |
| 20:20:33 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:8880:3cbe:369:d070) |
| 20:31:57 | | Quit _bilgus (Read error: Connection reset by peer) |
| 20:35:25 | | Quit MrZeus (Ping timeout: 240 seconds) |
| 20:38:58 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:31:50 | efqw | How much effort would be required to implement a soft keypad? |
| 21:32:33 | efqw | This would make those x1000[e] touchscreen-only devices viable targets. |
| 21:33:00 | efqw | Well, sans the tiny stuff like the FiiO M5 |
| 21:36:27 | | Quit ac_laptop (Ping timeout: 258 seconds) |
| 21:55:25 | | Quit cockroach (Quit: leaving) |
| 22:00 |
| 22:06:27 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:8880:3cbe:369:d070) |
| 22:23:19 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 22:32:05 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 22:38:59 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:18:58 | braewoods | efqw: it would probably require you to split the screen. |
| 23:19:07 | braewoods | part would be for the regular UI |
| 23:19:23 | braewoods | the rest would be for translating inputs for the keypad |
| 23:19:42 | braewoods | it would require some kind of touch translation system |
| 23:20:04 | braewoods | you can get the raw inputs from /dev stuff |
| 23:20:38 | braewoods | so you're talking 1), changes to the UI so it only uses part of the screen. |
| 23:20:59 | braewoods | 2), also making it draw whatever keypad arrangement you devise |
| 23:21:07 | braewoods | then third |
| 23:21:27 | braewoods | a system for translating the keypad zones to events internally |
| 23:25:01 | efqw | I have to admit that's much more than I could handle. |
| 23:25:45 | braewoods | yea.. desktop linux has that all solved but these devices aren't nearly beefy enough for that. |
| 23:26:03 | efqw | The m3k was easy because the kernel implemented the touchpad stuff at driver level, so we never had to deal with it in the first place. |
| 23:26:38 | efqw | All we get are fixed keycodes that corresponds to the physical button regions on the hardware. |
| 23:26:42 | braewoods | with Linux though touchscreen support is limited just to event reporting |
| 23:26:52 | braewoods | it's up to userspace to do something useful with it |
| 23:27:19 | braewoods | there's a whole stack of support software in userspace for touchscreens |
| 23:27:23 | braewoods | udev, etc |
| 23:27:54 | braewoods | which is ultimately exposed in xinput2 |
| 23:28:13 | efqw | yea, that might be too much for the poor x1000[e] with only 32/64MB of ram |
| 23:28:22 | braewoods | it would. |
| 23:28:59 | braewoods | my favorite TS to date were wacom tablets |
| 23:29:05 | braewoods | very nicely supported |
| 23:30:12 | efqw | Writing a simple daemon that processes the touchscreen events might be an option, and then we can just use swipe gestures for navigation. |
| 23:31:23 | efqw | up/down for scrolling, tap for enter |
| 23:32:03 | efqw | This is the minimal amount of gestures that would make me consider the touchscreen to be "useful" |
| 23:33:44 | braewoods | efqw: you basically have to create your own input stack to handle desktop-like devices. |
| 23:33:53 | braewoods | since there's no HW buttons |
| 23:33:59 | braewoods | those are simple to handle |
| 23:34:11 | braewoods | touch requires you to do a lot more |
| 23:34:21 | braewoods | but |
| 23:34:33 | braewoods | it shouldn't be too hard if you're used to writing GUI toolkits |
| 23:34:35 | braewoods | lol |
| 23:34:51 | braewoods | which is basically what you'd have to do to port to a touchscreen |
| 23:34:55 | braewoods | with limited resources |
| 23:35:13 | efqw | There are hw buttons. My target is the FiiO M3 Pro, which has the same amount of hw buttons as the M3K does. |
| 23:35:14 | braewoods | maybe there's some libraries that can help though |
| 23:35:27 | efqw | pwr/vol+/vol-/play&pause |
| 23:35:30 | braewoods | i recall directfb |
| 23:36:12 | braewoods | https://elinux.org/DirectFB |
| 23:36:34 | braewoods | though |
| 23:36:36 | efqw | so technically we're only missing ffwd/rewind/up/down/confirm/back |
| 23:37:02 | braewoods | i don't know if directfb would work on ARM |
| 23:37:15 | Stanley00 | I'm not sure, but when I tried with HAVE_TOUCHSCREEN for my M5, rockbox somehow can handle touch gesture itself, eg I can scroll the screen by swipe up/down |
| 23:37:36 | efqw | That's good to know |
| 23:38:24 | Stanley00 | it's just good part, bad part is that I cannot understand/trace how it worked, so I just skip HAVE_TOUCHSCREEN all together and use it just as simple touchpad, with 9 button region |
| 23:38:27 | efqw | I'm not all that interested in the M5 because the battery is way too small. |
| 23:38:44 | Stanley00 | but you can trace HAVE_TOUCHSCREEN to see related code |
| 23:39:36 | efqw | And since it's quite a pricey device, I'm probably not gonna buy one just to test the touchscreen stuff. Bluetooth is nice but it's not all that useful if I can't get it to work with rb. |
| 23:39:56 | Stanley00 | yup, I just let the battery die yesterday becasue I thought I already shutdown rockbox, but it still on, and draw battery overnight, doing nothing =]] |
| 23:40:16 | efqw | ah, you might hit the same problem as I did |
| 23:40:34 | efqw | https://www.irccloud.com/pastebin/Hd6HqsLD/ |
| 23:40:55 | efqw | The fiio kernel on my m3k does this if I just call `shutdown` |
| 23:41:10 | efqw | It freaks out and doesn't actually power off the device. |
| 23:41:33 | Stanley00 | ah, thanks for the info, let me check for that on my fiio later today |
| 23:42:19 | efqw | There's no way to check it directly unless you take the player apart and connect the UART console |
| 23:42:49 | efqw | I pulled my m3k apart and hooked up the serial console. |
| 23:43:59 | Stanley00 | hmm... too bad, I don't have tools for that |
| 23:44:10 | Stanley00 | best I can do is just adb shell |
| 23:44:50 | efqw | oh, the m5 had adb shell? |
| 23:45:06 | Stanley00 | yes |
| 23:45:27 | efqw | that's nice, the m3k had the android stuff disabled in the kernel |
| 23:45:39 | Stanley00 | I *accidentally* discover that feature when looking in their firmware |
| 23:46:02 | efqw | without taking apart the device, you have to overwrite the system partition to get a root shell over USB gadget serial |
| 23:46:38 | Stanley00 | lucky, adb shell is already in root, that's why I'm here :3 |
| 23:47:07 | efqw | I wonder how's the m3 pro like. I can see the rootfs but I don't know about the kernel, I'd have to buy one of those to see if adb actually works or not. |
| 23:47:34 | Stanley00 | anyway, M5 firmware looks more like in development state, many debuging info is still there |
| 23:47:56 | efqw | the player binary on the m3k and m3 pro are unstripped |
| 23:48:19 | Stanley00 | on m5, they have player.symbol and also gdb binary there |
| 23:48:28 | Stanley00 | I heard that m3k also have gdb too |
| 23:48:30 | Stanley00 | right? |
| 23:48:33 | efqw | yeah, the m3 pro had gdb too |
| 23:48:40 | efqw | m3k doesn't |
| 23:49:40 | Stanley00 | ah, I see |
| 23:50:43 | efqw | by the way, check your /data/userfs/app.log |
| 23:51:05 | efqw | you might want to delete that and symlink it to /dev/null |
| 23:51:43 | efqw | on the m3k it writes some incredibly verbose log to the flash, with zero compression |
| 23:51:49 | Stanley00 | thanks, I already did that, and also kernel.log |
| 23:51:56 | Stanley00 | I don't need those for now |
| 23:51:58 | efqw | yeah, that's good :) |
| 23:52:27 | | Quit [7] (Ping timeout: 260 seconds) |
| 23:52:42 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 23:52:48 | efqw | what annoys me is that the data partition is a separate ubi device, not an ubi *volume* |
| 23:53:11 | efqw | wear levelling doesn't work across different ubi devices |
| 23:53:53 | efqw | I understand why they did this (it's easier to update, since the recovery doesn't have to deal with ubi volumes) but it's incredibly bad for the flash |
| 23:54:18 | efqw | It doesn't help that the database is written to that tiny partition too |
| 23:55:20 | Stanley00 | I think the devs at FiiO just have so much pressure that they cannot think out carefully :P |
icon identifies that the person is a core developer (has commit access).