| 00:14:13 | *** | Saving seen data "./dancer.seen" |
| 00:27:55 | | Join advcomp2019 [0] (~advcomp20@65-131-167-42.sxct.qwest.net) |
| 00:27:55 | | Quit advcomp2019 (Changing host) |
| 00:27:55 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 00:30:11 | | Quit advcomp2019__ (Ping timeout: 260 seconds) |
| 01:00 |
| 01:52:07 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:00 |
| 02:14:14 | *** | Saving seen data "./dancer.seen" |
| 02:29:54 | | Quit reductum (Ping timeout: 240 seconds) |
| 02:53:05 | | Quit bonfire (Remote host closed the connection) |
| 03:00 |
| 03:01:35 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 04:00 |
| 04:10:31 | commate | petur: Are you icelandic? |
| 04:14:16 | *** | Saving seen data "./dancer.seen" |
| 04:50:51 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 04:58:57 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 05:00 |
| 05:03:06 | petur | commate: no, just an affinity ;) |
| 05:23:23 | | Quit krabador (Remote host closed the connection) |
| 05:36:38 | | Join langest [0] (~langest@89.238.183.61) |
| 06:00 |
| 06:11:34 | | Quit Oksana (Ping timeout: 240 seconds) |
| 06:14:18 | *** | Saving seen data "./dancer.seen" |
| 06:38:38 | | Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) |
| 06:39:22 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 06:44:03 | | Quit schiz (Killed (wolfe.freenode.net (Nickname regained by services))) |
| 07:00 |
| 07:49:29 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 08:00 |
| 08:02:18 | | Join massiveH [0] (~massiveH@ool-18e4eaeb.dyn.optonline.net) |
| 08:14:21 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:46:43 | speachy | the rockbox-sf mailing list (logging the tracker emails) is working again. |
| 09:46:56 | langest | It seems like my player stops when I charge it. Am I able to charge and play music at the same time with rockbox? Doesn't seem to accept any input when the charging cable is connected... |
| 09:47:05 | speachy | I think the rockbox-cvs list is now okay too, but testing that will have to wait until the next commit lands |
| 09:47:20 | speachy | langest, hold down select when you plug it in |
| 09:48:37 | speachy | the usb code (on the hosted targets, anyway) doesn't have a way to automagically determine if we should go charge-only or into disk mode. |
| 09:48:55 | langest | Works, thanks. |
| 09:50:28 | langest | I see. But couldn't you at least check if it is playing something? Or is the usb code on a lower level so that it doesn't have any access to rockbox states? |
| 09:51:07 | speachy | it's pretty low level. The problem is we won't know what to do without prompting the user. |
| 09:52:30 | | Quit massiveH (Quit: Leaving) |
| 09:53:54 | langest | I guess there is some technical limitation for that.. Even though from a user perspective it is hard to imagine it being improssible since my other devices usually can continue in whatever state they are in when I plug in the charging adapter. Except for a stupid BT speaker I have, maybe it has some similar problem.. |
| 09:54:23 | speachy | there's no guarantee the file that was playing will still be there upon unplug |
| 09:56:03 | langest | Alright, but wouldn't that be an exception that fairly easy to manage? (I don't want to criticize the design, I'm just curios if you have the time and want to explain, otherwise I might look at the code at some point) |
| 09:57:40 | speachy | the bigger fish to fry is the "what to do upon usb insertion" |
| 09:58:09 | speachy | since the widget (ie rockbox) has to initiate the USB handshaking to the host. |
| 09:59:10 | | Quit Moarc (Read error: Connection reset by peer) |
| 09:59:46 | langest | And it isn't possible to do the handshake while continuing to play the current file? |
| 10:00 |
| 10:00:06 | speachy | short answer is "depends on the mode" |
| 10:00:11 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 10:00:14 | langest | ok |
| 10:00:23 | speachy | becuase in USB mode we have to give exclusive access to the storage to the usb host |
| 10:00:33 | speachy | on most targets, that is. |
| 10:00:46 | langest | ah, so that's the problem |
| 10:00:52 | langest | thanks |
| 10:01:17 | speachy | on the hosted targets (like the x3ii) Rockbox is an application like any others, but the OS still needs to know to disconnect the filesystem from the OS so applications can't modify it. |
| 10:02:06 | speachy | that's because we use mass storage mode. If we exported MTP mode instead, then that wouldn't be necessary. |
| 10:04:11 | langest | I see. |
| 10:05:48 | speachy | but that's not a trivial undertaking (for native targets, anyway) |
| 10:06:13 | speachy | but! We'd still probably need to prompt the user to determine the right thing to do. |
| 10:11:11 | langest | Yes |
| 10:12:14 | langest | From a user perspective it might have been more helpful to get a popup prompting me. But now that I know I need to press select I prefer the current implementation. |
| 10:12:37 | langest | I guess I should have read the manual. |
| 10:14:25 | *** | Saving seen data "./dancer.seen" |
| 10:17:23 | speachy | that might not be in the manual. Or at least it can vary based on the target |
| 10:26:36 | | Quit Moarc (Read error: Connection reset by peer) |
| 10:28:36 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 10:35:56 | speachy | oh, langest, how's the x3ii been under normal usage? does the keymap seem sane so far? |
| 11:00 |
| 11:20:54 | | Join hugo_ [0] (~hugo@dslb-094-218-027-039.094.218.pools.vodafone-ip.de) |
| 11:21:55 | | Quit petur (Read error: Connection reset by peer) |
| 11:22:00 | hugo_ | Hey, does anyone have the AUPD Decryption Program? It was removed from rockbox website a long time ago. |
| 11:29:40 | langest | I haven't leared any shortcuts (if there are any). But back, select, left/up and right/down are all on the correct keys. |
| 11:30:21 | langest | I'm trying to figure out what select does. It seems to work like back in menues and show currently plaing sometimes. |
| 11:30:30 | langest | *playing |
| 11:50:15 | | Quit hugo_ (Remote host closed the connection) |
| 11:50:33 | | Join hugo_ [0] (~hugo@dslb-094-218-027-039.094.218.pools.vodafone-ip.de) |
| 11:52:28 | langest | I'm trying to figure out how timestretch works. I enabled it in settings and am trying to find pitch and timestretch on the wps screen but can't seem to find it. |
| 12:00 |
| 12:07:45 | | Quit hugo_ (Remote host closed the connection) |
| 12:08:04 | | Join hugo_ [0] (~hugo@dslb-094-218-027-039.094.218.pools.vodafone-ip.de) |
| 12:14:27 | *** | Saving seen data "./dancer.seen" |
| 12:21:39 | | Join MrZeus [0] (~MrZeus@89-168-118-226.dynamic.dsl.as9105.com) |
| 12:24:21 | langest | Any tips on how to get this working? |
| 12:28:39 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 12:55:07 | | Join hugo__ [0] (~hugo@dslb-094-218-027-039.094.218.pools.vodafone-ip.de) |
| 12:55:19 | | Quit hugo_ (Remote host closed the connection) |
| 12:58:40 | fs-bluebot | Build Server message: New build round started. Revision 32b03d7, 292 builds, 9 clients. |
| 13:00 |
| 13:17:07 | fs-bluebot | Build Server message: Build round completed after 1108 seconds. |
| 13:17:10 | fs-bluebot | Build Server message: Revision 32b03d7 result: All green |
| 13:40:00 | pixelma | langest: look for how to get to the quickscreen in our manuals (don't know which device you're talking about) |
| 13:41:40 | | Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr) |
| 14:00 |
| 14:00:04 | langest | thanks, I'll have a look. (xDuoo x3ii, I don't think it has any manual yet) |
| 14:01:11 | langest | It doesn't appear in the quick screen. |
| 14:08:37 | | Quit advcomp2019 (Ping timeout: 264 seconds) |
| 14:09:59 | | Join advcomp2019 [0] (~advcomp20@65-131-184-52.sxct.qwest.net) |
| 14:09:59 | | Quit advcomp2019 (Changing host) |
| 14:09:59 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 14:14:29 | *** | Saving seen data "./dancer.seen" |
| 14:30:43 | | Quit ZincAlloy (Quit: Leaving.) |
| 14:31:29 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:7400:c145:aed7:cc4a) |
| 14:48:24 | | Quit hugo__ (Quit: Leaving) |
| 14:50:00 | mendel_munkis | I am trying to extend g#120. the issue with it as stands is that some plugins like to write directly to the framebuffer and since the plugin api can only contain constants plugins can't properly handle a changing framebuffer. |
| 14:50:03 | fs-bluebot | Gerrit review #120 at http://gerrit.rockbox.org/r/120 : lcd drivers: Convert lcd_[remote_]framebuffer to a pointer by Jonathan Gordon |
| 14:51:44 | mendel_munkis | I see two possible solutions, either passing a pointer to the framebuffer pointer in the API, or entirely removing plugin direct framebuffer access and adding a function for arbitrary framebuffer writes. |
| 14:53:56 | mendel_munkis | As I see it the main con with the first option is that its ugly and breaks up the "format" of the API, the main issue with the second is that for any plugins which are ports and assume that they have control of the framebuffer far more function wrapping needs to be done. |
| 14:54:11 | mendel_munkis | Does anyone else have any comments on this? |
| 15:00 |
| 15:17:22 | speachy | we'll want direct fb access. |
| 15:18:07 | speachy | exporting a pointer to the fb makes more sense. |
| 15:18:21 | speachy | a pointer to a pointer to the fb, that is |
| 15:19:18 | speachy | most plugins don't update the display that often, but others (esp games) need all the performance they can get. |
| 15:19:58 | speachy | as long as we make some assumptions.. like when a plugin is running, the rb core won't change the active fb out from under the plugin. |
| 15:27:32 | mendel_munkis | speachy: unless the plugin asks it to. |
| 15:29:04 | speachy | of course |
| 15:34:20 | mendel_munkis | but I don't need to add a check if I don't add a framebuffer switch anywhere a plugin could be running correct? |
| 15:34:54 | mendel_munkis | in other words the caller should check not the switching function |
| 15:35:00 | speachy | yeah. |
| 15:35:09 | mendel_munkis | when put that way it sounds obviously wrong however |
| 15:36:04 | speachy | anything that switches the fb should switch it back when they're done. |
| 15:36:19 | speachy | the low-level display functions should always operate using the active pointer |
| 15:36:49 | speachy | (that is to say the low-level device drivers) |
| 15:37:17 | speachy | but everything that writes to the fb should use the fb they allocated so if they update in the background they don't trash the one being displayed |
| 15:37:19 | speachy | if that makes sense |
| 15:37:36 | mendel_munkis | speachy: why should the fb always be switched back? |
| 15:37:40 | speachy | mind you, I'm just describing how I think it should all work, which isn't necessarily how it's actually implemented. |
| 15:38:29 | mendel_munkis | maybe I want to add a setting to halve my devices resolution using a smaller framebuffer |
| 15:38:33 | speachy | because if you never switch it back, why not just use the "global" fb to begin with, and not waste the RAM with a secondary one. |
| 15:39:01 | speachy | the idea being your code wants its own playground, and the rest of the system should leave that playground alone. |
| 15:39:09 | mendel_munkis | I see |
| 15:42:10 | speachy | but that's the theory anyway. |
| 15:44:00 | mendel_munkis | as far as I can tell the way it works now is that every plugin is handed a pointer to the default fb and can ask the core to switch between it and whatever framebuffers it allocates. |
| 15:44:08 | speachy | rockbox's lcd_* functions all operate on the "current" fb. |
| 15:44:50 | mendel_munkis | but which means that that if something else switched framebuffers before the plugin starts weird things may happen |
| 15:47:04 | speachy | yep. |
| 15:47:15 | speachy | so it goes back to... what are you trying to accomplish? |
| 15:47:25 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 15:47:27 | speachy | and are you better off just doing a memcpy()? :) |
| 15:48:37 | mendel_munkis | speachy: my end goal is to use a differently sized framebuffer in place of the default one |
| 15:49:08 | mendel_munkis | my semi-immiedete goal is to have a framebuffer thats fb[y][x] instead if fb[x][y] |
| 15:49:58 | mendel_munkis | my current goal is to make the plugin api not dependent on the default framebuffer |
| 15:50:37 | speachy | the underlying hardware/drivers need a fb that corresponds to the physical display (rows/cols/depth) |
| 15:50:52 | | Quit Rower- (Ping timeout: 256 seconds) |
| 15:51:32 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 15:51:55 | mendel_munkis | of course. but how many of the screens on rockbox devices support multiple resolutions? |
| 15:52:14 | | Quit Rower (Ping timeout: 256 seconds) |
| 15:52:48 | speachy | none that I'm aware of. |
| 15:53:05 | mendel_munkis | and getting landscape (for which there is hardware support) working on the fuze+ has been a pet project of mine for years |
| 15:53:55 | speachy | so when you say "differently sized" are you just referring to rotation, or are you talking about arbitrary [smaller] sizes, or both? |
| 15:54:34 | speachy | rockbox doesn't handle run-time resolution/orientation changes. |
| 15:54:40 | mendel_munkis | I was referring to both. if noe of the rockbox hardware supports it however i'll settle for rotation |
| 15:55:01 | mendel_munkis | I am aware of that. it's a long term goal of mine to change that |
| 15:55:11 | mendel_munkis | (at least on my private build) |
| 15:55:28 | speachy | the hosted-on-android targets in theory can handle switching resolutions though there's still only one native output res for a given screen |
| 15:56:37 | speachy | it's not _that_ bad to add runtime rotation/etc but it'll come at a cost of code size and performance. |
| 15:57:04 | speachy | which hasn't historically been considered worth it. :/ |
| 15:57:15 | mendel_munkis | I am well aware. that's why I wasn't counting on getting it into mainline |
| 15:57:34 | mendel_munkis | (but at least I hope to see it in gerrit for anyone else who wants it) |
| 15:57:50 | speachy | I wouldn't discount it going into mainline; for example, a viable android port pretty much requires it |
| 15:58:32 | speachy | and I'd be willing to bet that a lot of the necessary incremental steps to make that happen would be valuable in their own right |
| 16:00 |
| 16:01:00 | mendel_munkis | and by the way the fuze+ screen supports multiple depths and sizes if I understand the datasheet |
| 16:01:01 | speachy | and the most-constrained targets (ie archos) should just get taken out back and shot |
| 16:06:47 | pixelma | langest: oh, I misremembered myself. There should be a pitchscreen |
| 16:07:40 | pixelma | I don't use pitch or timestretch or the like often |
| 16:07:56 | mendel_munkis | of course in my dream world greylib is part of the lcd drivers not the pluginlib |
| 16:08:05 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 16:10:54 | | Quit Rower- (Ping timeout: 240 seconds) |
| 16:11:06 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 16:12:49 | | Quit Rower (Ping timeout: 264 seconds) |
| 16:13:08 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 16:14:31 | *** | Saving seen data "./dancer.seen" |
| 16:15:49 | | Quit Rower- (Ping timeout: 264 seconds) |
| 16:19:23 | langest | pixelma: Ok, I suppose you don't know how to get to the pitchscreen. |
| 16:22:44 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 16:25:34 | | Quit Rower (Ping timeout: 240 seconds) |
| 16:26:04 | mendel_munkis | langest: what happens if you hold home? |
| 16:26:37 | mendel_munkis | from th while playing screen |
| 16:26:39 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 16:27:22 | | Quit Rower- (Ping timeout: 256 seconds) |
| 16:27:34 | fs-bluebot | Build Server message: New build round started. Revision dfa8fd8, 292 builds, 9 clients. |
| 16:27:43 | mendel_munkis | to get to the pitch screen you can hold play on the WPS to get the context menu. the last option on the context menu should be pitch. |
| 16:28:58 | langest | Holding play did the trick. Thanks. |
| 16:29:32 | mendel_munkis | langest: the effect of holding play should be a setting you can change |
| 16:29:50 | mendel_munkis | (In case you want to use the hotkey for something else) |
| 16:30:38 | langest | (y) |
| 16:33:01 | | Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 16:36:01 | | Quit Rower (Ping timeout: 265 seconds) |
| 16:39:37 | | Quit Rower- (Ping timeout: 258 seconds) |
| 16:41:10 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 16:44:16 | fs-bluebot | Build Server message: Build round completed after 1002 seconds. |
| 16:44:17 | fs-bluebot | Build Server message: Revision dfa8fd8 result: All green |
| 16:48:12 | | Quit langest (Remote host closed the connection) |
| 17:00 |
| 17:14:43 | | Quit lebellium (Quit: Leaving) |
| 17:35:25 | | Quit ZincAlloy (Quit: Leaving.) |
| 17:39:49 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:84cb:69d3:b335:7cc6) |
| 17:41:10 | | Quit ZincAlloy (Client Quit) |
| 17:54:42 | pamaury | mendel_munkis: just saw some stuff on the fuze+. Supporting landscape mode on the fuze+ is very easy, the controller is quite flexible about how you push the pixels. It doesn't support multiple resolutions though. The controller just assumes a pixel is a pixel, it doesn't care that much about the actual resolution but it won't be able to scale. |
| 17:55:17 | pamaury | However the cpu on the fuze+ has a pixel co-processor that supports non-integer scaling so in principle, it could support multiple resolutions that way. |
| 17:57:32 | mendel_munkis | however the screen does support partial use |
| 17:57:42 | * | mendel_munkis wonders if that would save on battery |
| 17:58:22 | mendel_munkis | pamaury: i have some code you wrote for setting the correct registers for orientation flipping |
| 18:00 |
| 18:13:30 | | Quit petur (Quit: Leaving) |
| 18:14:35 | *** | Saving seen data "./dancer.seen" |
| 18:16:25 | | Quit pamaury (Ping timeout: 264 seconds) |
| 18:28:35 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 18:39:40 | | Quit dys (Ping timeout: 246 seconds) |
| 18:43:51 | | Join PimpiN8 [0] (~PimpiN8@213.232.87.64) |
| 18:51:20 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 18:56:00 | | Join zalckos [0] (~avocado@82.169.55.180) |
| 18:58:04 | | Quit sakax (Quit: Leaving) |
| 19:00 |
| 19:10:54 | mendel_munkis | speachy: does it make sense to dereference the pointer for the lua API or leave dereferencing to the lua plugins to maintain API similarity? |
| 19:11:25 | speachy | I guess that would depend on its users. |
| 19:11:55 | speachy | all else being equal similarity is better but lua doesn't provide a complete 1:1 mapping. |
| 19:14:22 | mendel_munkis | I cant even figure out how to dereference a pointer in lua |
| 19:39:12 | | Join __BILGUS_ [0] (41ba23be@65.186.35.190) |
| 19:39:47 | __BILGUS_ | mendel_munkis the devices all have different requirements for pixel ordering & stride |
| 19:40:09 | __BILGUS_ | there are a bunch of macros that switch to the proper format |
| 19:40:29 | mendel_munkis | I am well aware. |
| 19:40:38 | __BILGUS_ | in lua I had to do all the conversion in bin |
| 19:40:49 | mendel_munkis | bin? |
| 19:41:00 | __BILGUS_ | in the plugin binary |
| 19:41:40 | __BILGUS_ | it'd be nice to be able to natively handle them but that seems like a tall order |
| 19:45:56 | __BILGUS_ | speachy what do you mean it's not 1:1? |
| 19:46:19 | speachy | you created a perfect lua mapping for each rockbox API? |
| 19:47:51 | __BILGUS_ | oh I thought you were saying pixel mapping |
| 19:48:05 | speachy | yeah :) |
| 19:48:39 | __BILGUS_ | no but its pretty fully reflected |
| 19:48:40 | speachy | and IMO a perfect 1:1 api mapping would be insane given the organic mess that is our internal (and plugin) API... |
| 19:49:20 | __BILGUS_ | lua is not nicewhen it comes to that |
| 19:50:29 | __BILGUS_ | mendelmunkis if you have any questions about lua esp my patches feel free to ask |
| 19:51:08 | __BILGUS_ | lua is not my goto language lets just say that but I know a whole lot about the internal workings after all those patches |
| 19:53:29 | mendel_munkis | nope you convinced me its saner to just have the runtime dereference the double pointer instead of expecting the lua app to. |
| 20:00 |
| 20:14:39 | *** | Saving seen data "./dancer.seen" |
| 20:16:10 | | Quit zalckos (Quit: Leaving) |
| 20:24:48 | | Quit MrZeus (Ping timeout: 256 seconds) |
| 21:00 |
| 21:21:06 | | Quit PimpiN8 (Quit: Textual IRC Client: www.textualapp.com) |
| 22:00 |
| 22:11:24 | | Quit __BILGUS_ (Remote host closed the connection) |
| 22:14:43 | *** | Saving seen data "./dancer.seen" |
| 22:46:49 | | Join reductum [0] (~weechat@cpe-104-175-169-123.socal.res.rr.com) |
| 23:00 |
| 23:54:34 | | Quit TheSeven (Disconnected by services) |
| 23:54:42 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
icon identifies that the person is a core developer (has commit access).