00:16:30 | | Quit petur (Remote host closed the connection) |
00:46:17 | *** | Saving seen data "./dancer.seen" |
00:55:22 | | Quit ender` (Quit: Why shouldn't truth be stranger than fiction? Fiction, after all, has to make sense. — Mark Twain) |
01:00 |
01:04:39 | | Quit Moarc (Ping timeout: 256 seconds) |
01:04:43 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
01:05:50 | | Quit JanC (Ping timeout: 250 seconds) |
01:05:58 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
01:06:10 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
01:23:02 | | Quit ZincAlloy (Quit: Leaving.) |
01:59:58 | | Quit Rondom (Remote host closed the connection) |
02:00 |
02:00:43 | | Join Rondom [0] (~rondom@2a03:b0c0:3:d0::6b:1) |
02:06:44 | __builtin | hmm, I'm getting a crash in pcm_play_data() |
02:08:17 | __builtin | oh.... I see |
02:08:31 | __builtin | the format is interleaved PCM, as in stereo, right? |
02:21:30 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
02:24:58 | | Quit krnlyng (Ping timeout: 265 seconds) |
02:37:34 | | Join krnlyng [0] (~liar@77.117.64.182.wireless.dyn.drei.com) |
02:46:18 | *** | Saving seen data "./dancer.seen" |
03:00 |
03:57:46 | | Quit Marex (Ping timeout: 265 seconds) |
03:58:23 | | Join Marex [0] (~Marex@195.140.253.167) |
04:00 |
04:05:53 | | Quit Rondom (Remote host closed the connection) |
04:08:20 | | Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) |
04:46:20 | *** | Saving seen data "./dancer.seen" |
04:49:01 | | Quit michaelni (Ping timeout: 260 seconds) |
05:00 |
05:00:47 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
05:09:30 | | Quit krabador (Remote host closed the connection) |
05:52:44 | | Quit prof_wolfff (Ping timeout: 250 seconds) |
05:56:24 | | Quit [Saint] (Remote host closed the connection) |
05:57:22 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
06:00 |
06:08:10 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
06:22:08 | | Quit [7] (Ping timeout: 245 seconds) |
06:22:19 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
06:22:34 | | Quit toli (Ping timeout: 256 seconds) |
06:24:06 | | Quit prof_wolfff (Ping timeout: 268 seconds) |
06:27:53 | | Join toli [0] (~toli@ip-62-235-197-253.dsl.scarlet.be) |
06:44:33 | | Quit Bilgus (Quit: Page closed) |
06:46:23 | *** | Saving seen data "./dancer.seen" |
06:50:20 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
06:52:24 | | Quit duo8 (Ping timeout: 260 seconds) |
06:52:24 | | Join sth [0] (~ZNC-SRV-H@171.234.233.171) |
07:00 |
07:13:31 | | Join BIll [0] (615e1c38@gateway/web/freenode/ip.97.94.28.56) |
07:13:54 | | Nick BIll is now known as Guest39529 (615e1c38@gateway/web/freenode/ip.97.94.28.56) |
07:14:30 | Guest39529 | DJComputerguy |
07:14:32 | Guest39529 | oops |
07:14:42 | | Nick Guest39529 is now known as DJComputerguy (615e1c38@gateway/web/freenode/ip.97.94.28.56) |
07:14:47 | DJComputerguy | there we go |
07:15:12 | DJComputerguy | Hello people of the internet |
07:15:59 | DJComputerguy | I am thinking about installing Rockbox on my 3rd Gen iPod, are there any benefits to using this firmware? |
07:50:57 | | Join The_Prospector|2 [0] (~The_Prosp@c-73-239-179-79.hsd1.wa.comcast.net) |
07:52:28 | alexbobp | DJComputerguy: in my opinion, the ipod stock firmware is trash. that's subjective I guess. rockbox has many features but tell us how you use the device currently |
07:53:08 | alexbobp | personally I find it absurd to not have playlist editing features on the device :P |
07:53:16 | DJComputerguy | I just got the thing today, im the type of guy that likes to mod his stuff, no matter what it is |
07:53:36 | alexbobp | well then do it! it will dual boot with the original firmware anyways so you can sample both |
07:54:13 | | Quit The_Prospector (Ping timeout: 244 seconds) |
07:54:28 | DJComputerguy | can i put the rockbox firmware on the device using the USB 30 pin Dock Cable? or do i need the Fire Wire one? |
07:55:36 | alexbobp | usb works |
07:55:46 | alexbobp | I don't even know if firewire would work |
07:56:14 | alexbobp | I didn't know there was a firewire cable for ipods tbh |
07:56:27 | sth | they used to be firewire only |
07:57:10 | DJComputerguy | My particular iPod (3rd Gen) can sync with usb, but cant charge via usb |
07:57:53 | DJComputerguy | i heared somewhere that u need the FireWire cable to restore, i honestly dont want to do it untl i can get me one of thee cables |
07:57:59 | DJComputerguy | these* |
08:00 |
08:01:02 | DJComputerguy | oh yeah, i heared something about being able to run classic gameboy games on this firmware, is it possible with the 3rd Gen iPod? |
08:08:02 | | Quit girafe (Read error: Connection reset by peer) |
08:15:30 | | Join petur [0] (~petur@91.183.48.77) |
08:15:30 | | Quit petur (Changing host) |
08:15:30 | | Join petur [0] (~petur@rockbox/developer/petur) |
08:18:55 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
08:19:28 | pamaury | __builtin: yes, pcm are interleaved |
08:21:41 | | Join petur2 [0] (~petur@91.183.48.77) |
08:21:44 | | Quit The_Prospector|2 (Quit: when in doubt, kernel panic) |
08:22:11 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
08:24:40 | | Quit petur (Disconnected by services) |
08:24:45 | | Nick petur2 is now known as petur (~petur@91.183.48.77) |
08:24:54 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:24:54 | | Quit petur (Changing host) |
08:24:54 | | Join petur [0] (~petur@rockbox/developer/petur) |
08:27:44 | | Quit pixelma (Quit: .) |
08:27:44 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
08:27:54 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
08:27:56 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
08:45:23 | | Quit pamaury (Ping timeout: 265 seconds) |
08:46:24 | *** | Saving seen data "./dancer.seen" |
08:48:03 | | Join wodz [0] (~wodz@94-75-75-29.home.aster.pl) |
09:00 |
09:10:51 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
09:57:44 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:3de2:a434:5e8c:309e) |
09:58:25 | | Quit elensil (Client Quit) |
10:00 |
10:09:38 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:3de2:a434:5e8c:309e) |
10:25:40 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
10:30:22 | | Join cryham_ [0] (~cryham@ip-94-42-235-87.multimo.pl) |
10:33:10 | | Quit cryham (Ping timeout: 265 seconds) |
10:33:18 | | Nick cryham_ is now known as cryham (~cryham@ip-94-42-235-87.multimo.pl) |
10:40:52 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
10:46:27 | *** | Saving seen data "./dancer.seen" |
10:51:32 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:98b0:ca0c:1d64:6c70) |
10:52:58 | | Quit pamaury_ (Ping timeout: 244 seconds) |
11:00 |
11:01:27 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
11:03:39 | wodz | pamaury: I diffed includes of 4760 and 4760b from the patch and the differences are in bdma, cpm, dmac, gpio, i2c, lcdc, ost, Changes are minor |
11:06:02 | pamaury | wodz: I produce a register of the jz4760b (it's on the wiki) |
11:06:32 | pamaury | I am very careful though, I found at least different versions of the jz4760(b) headers |
11:07:18 | pamaury | g#1279 |
11:07:20 | fs-bluebot | Gerrit review #1279 at http://gerrit.rockbox.org/r/1279 : regtools: add JZ4760B description by Amaury Pouly |
11:08:02 | pamaury | s/wiki/gerrit |
11:08:26 | wodz | I looked at this some time ago |
11:08:56 | wodz | I though it would be interesting to compare headers from the same version though |
11:09:12 | pamaury | ah sure |
11:09:54 | pamaury | the problem I encountered is that the headers are broken, several defines have mistake or plain don't compile (I guess they are unsused by ingenic) |
11:10:12 | pamaury | and the headers are not easily extracted automatically, there don |
11:10:16 | pamaury | 't follow any convention |
11:15:41 | pamaury | wodz: if you have the diff, you can post it somewhere and we can check the fields that differ, see if the gerrit desc is correct |
11:16:00 | pamaury | in fact the latest one is g#1366 |
11:16:02 | fs-bluebot | Gerrit review #1366 at http://gerrit.rockbox.org/r/1366 : jz4760b/regtools: fix/rename some register fields, add clock analyzer to qeditor by Amaury Pouly |
11:16:28 | pamaury | also I noticed that some fields have the same name but different positions, it's not just add/removed fields |
11:25:46 | wodz | pamaury: Is it possible to plug usb device emulated on qemu into real system? |
11:26:31 | pamaury | you mean you emulate the usb device in qemu and give it to the real host? |
11:26:41 | pamaury | not that I know |
11:27:06 | pamaury | I know two libraries that can do that: usb-ip and usb-vhci but I am not sure if qemu supports that |
11:27:52 | pamaury | however I think qemu supports the opposite: give a real usb device to an emulated host |
11:29:31 | wodz | pamaury: I was using the oposite some time ago, yes. But I am asking about running hwstub on emulated hw and interact with it |
11:31:36 | pamaury | maybe try asking qemu devs, this feature would be very useful (in our sim as well). I think the best option is usb-ip which is the kernel I think |
11:34:15 | pamaury | I guess we could try adding that feature but it's nontrivial stuff |
11:35:23 | wodz | adding anything to qemu is nontrivial |
11:39:32 | pamaury | yeah but I mean, emulating a usb controller is not trivial anyway |
11:59:45 | | Join robertd1 [0] (~as@201.208.225.40) |
12:00 |
12:46:31 | *** | Saving seen data "./dancer.seen" |
13:00 |
13:08:23 | pamaury | robertd1: hi, I think I made progress with nwz screen, at least I know why it's black |
13:10:06 | robertd1 | hi pamaury that is great. Why is it black? |
13:13:43 | pamaury | well it's a long story but basically the standard linux framebuffer interface refreshes the screen periodically (so if you write something it ends up on the screen). And this crap because you don't control timing. So Sony adds extensions to control double-buffering and refreshing. The OF switches to manual refresh mode and thus you need to explicitely tell the driver to refresh otherwise nothing is dipslayed and the screen is ...black |
13:14:38 | pamaury | I think it's actually a good thing, in Rockbox we can make sure of those extensions. But for the tool, I need to find how to restore the auto-refresh |
13:23:11 | robertd1 | :-/ that sounds awfully complicated. I guess there must be by accessing the nodes at the graphical user interface |
13:27:10 | pamaury | robertd1: I don't understand what you mean. It's not that complicated, just not very documented |
13:33:35 | | Quit ZincAlloy (Quit: Leaving.) |
14:00 |
14:18:21 | | Part robertd1 |
14:20:26 | | Join fs-bluebot_ [0] (~fs-bluebo@x4d0997a9.dyn.telefonica.de) |
14:21:57 | | Quit bluebrother (Read error: Connection reset by peer) |
14:22:44 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
14:24:24 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
14:31:19 | sth | if not refreshed it will be black? not just not changing? |
14:33:44 | | Join robertd1 [0] (~root@201.242.189.245) |
14:35:32 | wodz | pamaury: which sony devices are those you are working on currently? Maybe I'll look for something cheap to play with |
14:37:58 | sth | the semi-recent E series iirc |
14:38:01 | sth | E3xx |
14:40:37 | pamaury | wodz: basically anything in this list: NWZ-A10, NW-A20, NWZ-A720, NWZ-A810, NWZ-A820, NWZ-A840, NWZ-A850, NWZ-A860, NW-A910, NWZ-E050, NW-E060, NW-E080, NWZ-E350, NWZ-E450, NWZ-E460, NWZ-E470, NWZ-E550, NWZ-E570, NWZ-E580, NW-S10, NWZ-S510, NWZ-S610, NWZ-S630, NW-S640, NWZ-S710, NWZ-S730, NWZ-S740, NWZ-S750, NWZ-S760, NWZ-S770, NW-S780, NWZ-X1000, NW-ZX100 |
14:41:06 | wodz | pamaury: and which do you have (so I could look for something else) |
14:41:07 | pamaury | I cannot guarantee a 100% but those are all linux based and use the same-ish linux structure |
14:41:24 | pamaury | I have the E450 and E460. robertd1 has the A860 |
14:41:37 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
14:41:50 | wodz | ok, I'll look if I can find something |
14:42:17 | pamaury | I would recommend against something much older than E450 (or ask me first) because the very first generation seems slightly different |
14:42:48 | pamaury | just so you know, I might buy something like a A15 to try it on recent ones |
14:42:53 | pamaury | the e470 would be nice |
14:43:36 | pamaury | or of the e5x0 (e550, e570, e580) |
14:44:46 | | Quit robertd1 (Quit: Leaving.) |
14:45:14 | | Join robertd1 [0] (~root@201.242.189.245) |
14:45:32 | pamaury | wodz: don't hesistate to buy a S series, they are usually cheap as well |
14:46:25 | | Quit pamaury_ (Ping timeout: 265 seconds) |
14:46:35 | *** | Saving seen data "./dancer.seen" |
14:46:57 | pamaury | the sony nwz-e350 would too I guess |
14:47:55 | pamaury | wodz: I can also have a look on a french second hand website, buy it and send it to you |
14:48:54 | wodz | first I'll check what is available locally |
15:00 |
15:03:48 | wodz | I can get one of: nwz-e436f, nwz-s615f, nwz-e383, nwz-e474, nwz-a818, nw-a25 |
15:03:52 | wodz | pamaury: ^ |
15:05:56 | pamaury | a25 would be really nice, but probably more expensive. e470 would be useful. e383 is not linux based. e436 is not linux based. nwz-s615 is ok but kinda of old. Same of nwz-a818. |
15:06:18 | pamaury | so I would say either a25 or e470 or both ;) What are the prices ? |
15:06:34 | pamaury | I can get the e470 for around 50 euros which is not cheap |
15:06:53 | pamaury | and the a15 for around a 100 eur. I think the a25 is even more expensive |
15:07:40 | wodz | There is one auction for a25. I can see how it goes. |
15:08:44 | wodz | 474 is under 25eur |
15:09:07 | pamaury | I would say the 470, at this price it's definitely worth it |
15:09:14 | pamaury | and try the auction |
15:11:24 | pamaury | if the a818 and s615 are very cheap you are also buy them but it's unclear if the port will useful/successful, just give me a second to have a lookk |
15:12:02 | wodz | pamaury: Can you look if this looks like 470? http://allegro.pl/mp4-sony-nwz-e474-i6576395236.html |
15:12:14 | wodz | if so I'll buy it |
15:13:12 | pamaury | looks ok, as long as it's indeed the e474 ;) It's incredibly hard to tell the different from a photo |
15:22:10 | | Quit DJComputerguy (Ping timeout: 260 seconds) |
15:27:03 | | Quit wodz (Ping timeout: 260 seconds) |
15:38:26 | | Quit alexweissman (Remote host closed the connection) |
15:48:17 | | Quit prof_wolfff (Ping timeout: 265 seconds) |
15:53:41 | sth | pamaury why those in particular? |
15:53:51 | sth | some seems quite different from others |
15:57:17 | sth | (the A30 also doesn't run android so maybe that will work too) |
16:00 |
16:00:39 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
16:00:59 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
16:01:38 | sth | (there's also the e394) |
16:15:21 | | Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-61c.dhcp6-bl.indiana.edu) |
16:19:30 | pamaury | sth: they run linux |
16:19:37 | pamaury | the e394 doesn't run linux |
16:19:46 | sth | how can you tell? |
16:20:23 | pamaury | several sources but mostly Sony enforces the GPL and releases the kernel of all its linux devices |
16:22:12 | pamaury | the list above is slightly incomplete, it doesn't list anything after the a20 series, so a30, wm1a, wm1z and possibly others, but they tend to be incredibly expensive anyway |
16:23:03 | pamaury | the e393 uses the RKNanoD. I know because I disassembled it ;) It only has 1MB of ram |
16:24:03 | | Quit robertd1 (Ping timeout: 265 seconds) |
16:25:59 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
16:35:44 | | Join robertd1 [0] (~root@201.211.53.103) |
16:37:30 | | Quit alexweissman (Remote host closed the connection) |
16:41:56 | | Quit pamaury_ (Ping timeout: 265 seconds) |
16:46:39 | *** | Saving seen data "./dancer.seen" |
16:55:15 | | Quit pamaury (Remote host closed the connection) |
16:55:58 | | Quit petur (Read error: Connection reset by peer) |
16:56:18 | | Join alexweissman [0] (~alexweiss@149-160-182-186.dhcp-bl.indiana.edu) |
16:58:16 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
17:00 |
17:05:12 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:8d00:b8b7:b450:be48) |
17:41:17 | | Join smoke_fumus [0] (~smoke_fum@leased-line-195-222-90-170.telecom.by) |
17:49:36 | | Quit alexweissman (Remote host closed the connection) |
17:53:20 | | Join alexweissman [0] (~alexweiss@149-160-182-186.dhcp-bl.indiana.edu) |
17:53:43 | | Join petur [0] (~petur@rockbox/developer/petur) |
17:56:38 | | Quit alexweissman (Remote host closed the connection) |
18:00 |
18:08:50 | | Quit elensil (Quit: Leaving.) |
18:17:05 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
18:46:44 | *** | Saving seen data "./dancer.seen" |
18:56:40 | | Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-61c.dhcp6-bl.indiana.edu) |
19:00 |
19:32:27 | | Quit alexweissman (Remote host closed the connection) |
19:41:03 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
19:58:35 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
20:00 |
20:03:47 | | Quit __builtin (Ping timeout: 245 seconds) |
20:03:52 | | Join __builtin_ [0] (~xray@unaffiliated/franklin) |
20:14:31 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
20:17:31 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
20:43:14 | | Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) |
20:43:48 | | Join girafe [0] (~girafe@LFbn-1-8015-136.w90-112.abo.wanadoo.fr) |
20:45:12 | Bilgus | Question.. Selective backlighting (on buttonpress or context) I don't see any commits on this although this seems to be a pretty requested option along with a few patches covering it that seem to have been rejected. |
20:45:39 | Bilgus | !. Why haven't they been accepted is there some fundamental reason? |
20:45:47 | Bilgus | 1.* |
20:46:10 | | Join TheLemonMan [0] (~root@unaffiliated/thelemonman) |
20:46:25 | pamaury | Bilgus: can you be more precise about what you mean by selective backlight? |
20:46:47 | *** | Saving seen data "./dancer.seen" |
20:46:59 | pamaury | or point to a specific patch? |
20:47:15 | Bilgus | say turning on the back light only on the select button, play/pause or power and not turning it on on say Vol+or Vol- |
20:47:43 | Bilgus | https://www.rockbox.org/tracker/task/8400?string=backlight&project=1&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= |
20:49:43 | pamaury | I don't know about this particular patch but probably they overlooked something/broke targets or were too specific to a target |
20:50:06 | pamaury | people often forget the variety of targets with have and make assumptions that turn out to be wrong |
20:51:28 | Bilgus | the patches there were pretty specific on targets but I think the main problem is the key defines being hardcoded |
20:52:23 | pamaury | I think a good patch would allow the user to select the keys, not hardcode them. There is also the problem of context: do you want this in the WPS only? or not? People do not necessarily agree. |
20:52:51 | Bilgus | that is my next question well next several |
20:53:18 | Bilgus | so first is the context issue which shouldn't be too difficult |
20:54:02 | Bilgus | and for the selection I have started a plugin that is generic enough to allow you to select keys on many targets |
20:54:54 | Bilgus | but I wonder is it ok for a plugin to address a var within rockbox or should it be written to the config file and picked up from there? |
20:55:15 | pamaury | selecting keys might using for other purposes, like allowing keys on softlock |
20:55:33 | pamaury | (for targets with touchscreen/touchpad where you lock the touchpad but still want keys to register in some context) |
20:56:13 | Bilgus | I still think the plugin is the way to go although it isn't really that much code |
20:56:27 | pamaury | um that's a good question. I think a plugin is acceptable, we have several plugins for stuff like credits and file properties I think |
20:57:08 | pamaury | but maybe it's just simpler to integrate it into the main binary |
20:57:36 | Bilgus | the next thing would be how to make it generic enough to be used for other purposes maybe a get routine |
20:57:49 | Bilgus | sorry* GetKey routine |
20:58:39 | pamaury | well the setting system is quite flexible I think, you could create a new type of var of type KEYMASK, and even flags to add constraints (like physical buttons only, or leave at least one button unchecked, etc) |
20:59:11 | Bilgus | that is how I'm currently handling the selective backlighting |
20:59:57 | Bilgus | the next thing would be I suppose a handler to record the keys |
21:00 |
21:01:22 | pamaury | the key selection would have its own screen, you can have access to virtually any keys and events, even have its own context so that's not a problem. It would need to be nice though (ie not just a menu with on/off for each key if possible). Possibly a picture or some sketch where each key press toggles the button for example. And maybe a combo or special action to confirm/cancel. |
21:02:13 | Bilgus | I thought about that but it would get hairy quickly adding those for all the different targets |
21:02:39 | Bilgus | maybe a more generic overlay |
21:02:41 | pamaury | well you could have a default screen I guess, because it would indeed be a daunting task to do it for every target |
21:03:00 | Bilgus | like a Dpad and some other squares with key names |
21:03:32 | pamaury | some devices don't even have a D-pad, not even left/right, we have some crazy targets ;) |
21:03:40 | pamaury | and some have MANY buttons |
21:04:27 | Bilgus | Currently I have a bunch of conditionally defined button/name combos |
21:05:17 | Bilgus | I was thinking of just having the user press they key they want twice to record and long press anyu button to quit |
21:06:37 | pamaury | this looks confusing |
21:06:54 | Bilgus | it wouldn't be too hard to make a matrice of all they keys the device has based on this although screen space might be an issue on some targets |
21:07:50 | pamaury | My suggestion would be that any key press toggles the key (some on/off) but two keys are special: the exit and confirm keys would popup a yes/no message saying "Do you want to cancel/confirm or toggle the key?" |
21:07:57 | Bilgus | instead it could use a matrix of the keys and the user could highlight the ones they wanted |
21:08:40 | pamaury | the matrix would be okay but not as good in my opinion. But for a proof of concept you can start with the matrix |
21:09:24 | Bilgus | for instance |Vol+ |Play | Home |
21:09:31 | Bilgus | −−−−−−−−−−−−−−−−−−−−−−−−- |
21:09:53 | Bilgus | |Vol+ |Play | Home| |
21:09:56 | Bilgus | −−−−−−−−−−−−−−−−−−−−−− |
21:10:08 | Bilgus | |Vol -|Select| | |
21:12:36 | Bilgus | how hard is a scrolling context for the devices with many keys? |
21:15:02 | pamaury | not that hard I would say. But maybe a list is just simpler than a matrix for starters, this way you don't have to reimplement the whole screen. This can always be improved after. |
21:15:20 | pamaury | what is tricky is to make the screen nice and integrate with the theme |
21:15:41 | pamaury | and trust me when I say you want to avoid creating new themable contexts if possible ;) |
21:15:57 | pamaury | although ideally that what would be needed I think |
21:16:37 | Bilgus | well I cna see the font part being pretty easy how much more to a theme is there? |
21:17:30 | pamaury | you know everything, lines, shading, colors, all the stuff tat make it look nice |
21:18:04 | pamaury | if you just print some ugly squares it's not going to play nice with the rest of rockbox :D |
21:18:25 | * | pamaury is not claiming that Rockbox is particular beautiful either |
21:19:44 | Bilgus | so you think it would be better to have something in the main binary as opposed to a plugin? |
21:20:45 | pamaury | I think so |
21:23:12 | pamaury | you can ask other developers what they think of course (not that there are that many these days) |
21:23:44 | Bilgus | ok Ill start looking into this is there any current context that would give me a good example of the possibilities? the Wps perhaps? |
21:25:19 | pamaury | the wps is very complicated, give me a second |
21:27:39 | pamaury | I would suggest to look at apps/gui/settings.c just to see how settings are handled |
21:27:54 | pamaury | and look at apps/gui/yesno.c for a simple screen with a button context |
21:28:12 | [Saint] | Bilgus: I guess you could call me the resident 'theme expert'. |
21:28:23 | [Saint] | What is it exactly you're wanting to achieve? |
21:29:14 | pamaury | [Saint]: the discussion is about having settings that give a key bitmap (like what keys don't trigger backlight). And the key question is how the choice should be presented to the user |
21:29:36 | [Saint] | We do have this, kinda. |
21:30:02 | pamaury | I don't recall anything like that |
21:30:03 | [Saint] | There was a patch floating around on gerrit for ignoring keys during SW keylock. |
21:30:30 | pamaury | yeah but there are two different issues: 1) what you do bit it (SW keylock, backlight) 2) how the user chooses the keys |
21:30:35 | pamaury | *with it |
21:30:38 | [Saint] | expanding that to HW keylock sparked a 'should this ever happen?' discussion. |
21:31:01 | [Saint] | which the majority (IMO rightly) swung towards no. |
21:31:10 | pamaury | the problem is hand is 2): how do you give a nice screen to the user so he can select which keys he wants to allow |
21:31:31 | [Saint] | basically, you don't. |
21:31:54 | pamaury | well I am still of the opinion that it makes sense, on target with touchpad that's incredibly annoying |
21:32:14 | Bilgus | and that brings me back to using a plugin and yes on the fuze it is very needed |
21:32:28 | [Saint] | the premise discussed at the time was just offering a subset of options like 'volume', and 'skip/seek'. |
21:32:48 | [Saint] | allowing much else kinda defeats the purpose of the SW keylock entirely. |
21:33:29 | pamaury | [Saint]: the point is that there other such settings that make sense, like keys that don't enable the backlight and still perform an action |
21:33:36 | Bilgus | after you do the code its not too hard to allow every button using conditional defines and I'm more interested in conditional backlighting |
21:34:03 | pamaury | and it makes sense for targets with a touchpad as well. |
21:34:17 | [Saint] | you're aware of the 'first button press enables backlight' option I take it? |
21:34:31 | pamaury | yes, that's unrelated |
21:34:45 | pamaury | I mean this would have priority |
21:34:58 | Bilgus | be better if it was a first button press doen't ebable backlight imo |
21:35:23 | pamaury | if a key is chosen to not enable backligt then obviously the "first button press enable backlight" does not apply to it |
21:35:49 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
21:36:15 | Bilgus | saint do you think a plugin would be better recieved then? I like the Idea of adding to main but not if it is going to be rejected |
21:36:20 | [Saint] | I guess I am really struggling to imagine the use case that happens often enough to make the complexity a useful tradeoff. |
21:36:53 | [Saint] | Bilgus: there's no way to handle this behavior from a plugin elegantly. |
21:36:58 | pamaury | [Saint]: all the time? Like you are listening to the player, it is softlock because it's in your pocket, you want the vol+/- to register but not enable backlight because that's useless |
21:37:07 | Bilgus | either way it would just output a mask of the selected keys and the added code to main is minimal |
21:37:16 | pamaury | same with play/pause and skip |
21:37:54 | [Saint] | personally I just set a minimal backlight timeout. |
21:38:06 | [Saint] | it's not like this is going to save any amount of battery worth worrying about. |
21:38:12 | [Saint] | and if you're not looking at it, who cares? |
21:38:14 | Bilgus | I added an extra hour to my clip+ which I use daily for 8-10hrs by disabling BL on volume and track change for instance |
21:38:18 | pamaury | it's not only about power, like during the night |
21:38:22 | [Saint] | seems like a non-issue to me. |
21:38:28 | pamaury | you don't want the backlight to turn on |
21:38:42 | [Saint] | then use a 'night time' config. |
21:38:42 | pamaury | all smartphone do that nowadays |
21:38:49 | [Saint] | disable the backlight. |
21:38:53 | [Saint] | add a shortcut to the cfg. |
21:38:59 | Bilgus | try that on the clip+ |
21:39:14 | Bilgus | how do you get back in to enable it again |
21:39:51 | [Saint] | you can force a .cfg to load at each boot that overrides the main config. |
21:40:07 | pamaury | that's just....super user friendly really |
21:40:14 | [Saint] | so that backlight is always re-enabled at boot time. |
21:40:56 | Bilgus | what do you think the un-elegant part would be? |
21:41:04 | [Saint] | it may not be particularly user friendly but generally speaking I'm against settings because settings for all for what is annoying on a subset of devices for a use case we're not sure a majority even care about. |
21:41:15 | Bilgus | writing the mask to the config file> |
21:42:03 | pamaury | [Saint]: you can't honestly say that given the setting we already have ;) |
21:42:15 | pamaury | I discover some crazy one everything I read the manual |
21:42:26 | pamaury | and this one is often requested |
21:42:31 | Bilgus | ^^ |
21:42:34 | [Saint] | pamaury: yes I can because the overwhelming majority of those I have fought tooth and nail. |
21:42:39 | pamaury | and it's not on all targerts: only the ones with softlock |
21:43:22 | [Saint] | why limit it to only softlock? if it is a use case we're sure people actually want there doesn't seem to be a reason to. |
21:43:44 | pamaury | because almost all targets can't keys wih physical lock |
21:43:50 | pamaury | it's just plain impossible |
21:43:56 | pamaury | *can't read keys |
21:44:48 | [Saint] | Hmmm, I guess you're right. I hadn't thought ahead to the ifdef madness that would create for the few targets that can do it. |
21:45:31 | pamaury | it's not that bad: you create a HAVE_MY_SUPER_OPTION, then config.h enables for softlock, and if you want to add exception you just do it there |
21:46:02 | [Saint] | regarding in-core vs. plugin, I think that's pretty clear cut. |
21:46:15 | [Saint] | you'd want this (presumably) to work globally. |
21:46:29 | [Saint] | which would include viewers and plugins themselves. |
21:46:37 | pamaury | [Saint]: the plugin thing is just to select which keys to enable |
21:46:50 | pamaury | but I think it's better in-core anyway |
21:47:27 | [Saint] | I...oh. right. yeah, that would still be better in settings.c and friends. yes. |
21:47:49 | | Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-416.dhcp6-bl.indiana.edu) |
21:48:03 | [Saint] | I kinda had it in my head that OP wanted a plugin to govern playback while keeping the backlight happy, but I see what you're going for now. |
21:48:12 | Bilgus | Ok 2/2 then |
21:49:40 | [Saint] | brb |
21:49:42 | pamaury | So going back to that: you want to have a setting that gives the user the choice to select a subset of keys. How do you present that to the user: |
21:49:42 | pamaury | 1) a list -> simple but not nice |
21:49:42 | pamaury | 2) a matrix ? -> might be better but would need a custom drawn screen and theming |
21:49:42 | DBUG | Enqueued KICK pamaury |
21:49:42 | pamaury | 3) something else? |
21:49:51 | | Quit [Saint] (Quit: Quit.) |
21:50:30 | pamaury | the Fiio X1 actually has a nice solution but it's limited: you get three "pictures" showing the keys to enable and you use left/right to switch between them. Of course it only works because there are 3 possibilities only |
21:51:16 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
21:52:47 | [Saint] | pamaury: have you seen the way we handle the 'select directories to scan' UI for the database? |
21:53:09 | [Saint] | I'm thinking the same thing, but with a list of available/aplicable buttons instead of directories. |
21:53:22 | [Saint] | it's a fairly simple way of handling it. |
21:53:44 | pamaury | [Saint]: no, how does that work? |
21:54:10 | pamaury | is that a list when you press entries to enable/disable? |
21:54:26 | Bilgus | yep |
21:54:52 | [Saint] | yes, and you can also select all, or select all except *, or select all under *, etc. |
21:55:05 | [Saint] | and reset all selections. |
21:56:00 | pamaury | interesting, I need to look into this, this is basically option 1) but better. |
21:56:08 | | Quit alexweissman (Ping timeout: 260 seconds) |
21:56:24 | [Saint] | most elegant way I can think of handling it whilst not re-inventing the wheel, and potentially re-exposing a familiar way of governing selection. |
21:56:41 | pamaury | I was thinking about a third option: a screen that shows which keys are enabled and when you press a key it toggles it |
21:56:55 | pamaury | but that's a lot of work |
21:56:58 | Bilgus | the only reason i don't like the pictures one is the variety of device and few generic possibilities the list |
21:57:10 | [Saint] | code to do it is already there, it just currently works against the filesystem - jiggering it to work with a list of buttons shouldn't be difficult. |
21:57:15 | Bilgus | you could still have the particular key toggle the selection |
21:57:41 | Bilgus | long press of the key perhaps |
21:57:46 | [Saint] | the downside is that themes can fuck up the selector. |
21:57:47 | [Saint] | we have no out for that. |
21:58:01 | [Saint] | we do try and make sure that that screen enables the display of icons. |
21:58:13 | [Saint] | but if the theme disables icons, it makes it pretty much unusable. |
21:58:27 | [Saint] | and themes get the final call on overriding icon display. |
21:58:48 | [Saint] | we can say we'd really like a screen to use icons, but a theme can screw it up by hardcoding forcing icons off. |
21:58:55 | [Saint] | that's...a problem, I guess. |
21:59:02 | [Saint] | but it is a problem we already accept. |
21:59:42 | [Saint] | a plugin would have the same problem if we drew the lists using the core. |
22:00 |
22:00:06 | Bilgus | could always use ascii if no icon |
22:00:07 | | Join alexweissman [0] (~alexweiss@2001-18e8-2-28cc-f000-416.dhcp6-bl.indiana.edu) |
22:00:28 | [Saint] | eh - not really. |
22:00:39 | pamaury | Bilgus: I think the point is you don't really know if the theme enables it or not |
22:00:46 | [Saint] | right. |
22:01:38 | pamaury | but that's an acceptable limitation anyway I guess, I think it's more important to have something that is consistent with the rest of the UI, and create new theme contexts is a lot of work I guess |
22:02:00 | pamaury | [Saint]: does that filesystem selection thing uses the list theme? |
22:02:07 | [Saint] | yes. |
22:03:56 | [Saint] | and, yes. I think you're right. one of the most important things about this is trying to present a system that is potentially familiar and consistent. |
22:04:14 | Bilgus | ok Ill bb and start looking into the filesystem list |
22:18:39 | | Quit pixelma (Quit: .) |
22:18:39 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
22:20:29 | [Saint] | unfortunately you won't be able to just drag and drop the code from there to do what you want. |
22:20:45 | [Saint] | but there's a good portion of it already written to serve as an example. |
22:21:00 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
22:21:00 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
22:21:23 | [Saint] | you'll just be swapping out listing and selecting the current filesystem with a preformed (no need for it to be dynamic, I guess?) list of buttons for a given target. |
22:33:36 | | Quit lebellium (Read error: Connection reset by peer) |
22:34:11 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
22:39:07 | | Quit alexweissman (Remote host closed the connection) |
22:46:48 | *** | Saving seen data "./dancer.seen" |
22:54:36 | | Join alexweissman [0] (~alexweiss@149-160-182-186.dhcp-bl.indiana.edu) |
23:00 |
23:11:47 | | Quit petur (Remote host closed the connection) |
23:13:23 | | Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]) |
23:24:33 | Bilgus | well It will be formed at compile time so its semi dynamic I suppose Ill reuse my code from the plugin I started |
23:27:38 | pamaury | Bilgus: list are much* |
23:27:49 | pamaury | *much* simpler when they don't change dynamically |
23:28:02 | pamaury | ie you fill the list when you create it and then don't touch it |
23:28:39 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
23:29:58 | Bilgus | I was thinking that tehre would be a neeed to add/remove entries depending on the use case? |
23:30:49 | pamaury | it doesn't matter, the list is still not changing dynamically. Dynamically = during the life of the screen |
23:31:13 | pamaury | the screen is static, you don't add/remove entries when the user is interacting |
23:32:21 | Bilgus | got it.. |
23:32:28 | [Saint] | and the list of buttons is never going to change. |
23:32:59 | [Saint] | just needs to be written once, essentially. |
23:43:58 | Bilgus | do you think they should be items and subitems Directions/up,down,left,right | Actions/select,Play, FF,REW or just strictly a list Up|Down|Left|Right|Select|Play |
23:47:35 | | Quit alexweissman (Remote host closed the connection) |
23:48:43 | | Quit pamaury (Ping timeout: 265 seconds) |