| - paperManu (QUIT: Quit: WeeChat 4.1.1) (~paperManu@198.16.214.40) | 00:49 | |
| - chomwitt (QUIT: Ping timeout: 252 seconds) (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 01:29 | |
| + paperManu (~paperManu@198.16.214.40) | 01:48 | |
| - mjw (QUIT: Ping timeout: 264 seconds) (~mjw@gnu.wildebeest.org) | 02:20 | |
| - paperManu (QUIT: Ping timeout: 265 seconds) (~paperManu@198.16.214.40) | 03:18 | |
| - robin (QUIT: Read error: Connection reset by peer) (~robin@user/terpri) | 06:06 | |
| + robin (~robin@user/terpri) | 06:07 | |
| - Bertl (QUIT: Ping timeout: 248 seconds) (herbert@IRC.13thfloor.at) | 06:25 | |
| + Bertl (herbert@IRC.13thfloor.at) | 06:25 | |
| + chomwitt (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 07:33 | |
| - aloo_shu (QUIT: Ping timeout: 260 seconds) (~aloo_shu@90.166.98.89) | 09:39 | |
| + aloo_shu (~aloo_shu@255.pool85-51-18.dynamic.orange.es) | 09:41 | |
| - jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 10:04 | |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 10:05 | |
| - GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 10:29 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 10:30 | |
| - erle (QUIT: Ping timeout: 244 seconds) (~erle@user/erle) | 10:40 | |
| + mjw (~mjw@gnu.wildebeest.org) | 11:00 | |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 11:08 | |
| - Ar|stote|is (QUIT: Read error: Connection reset by peer) (~linx@149.210.16.106) | 11:14 | |
| + Ar|stote|is (~linx@149.210.16.64) | 11:21 | |
| + andypiper (~andypiper@89.36.117.58) | 11:25 | |
| - Ar|stote|is (QUIT: Ping timeout: 245 seconds) (~linx@149.210.16.64) | 11:46 | |
| + Ar|stote|is (~linx@149.210.17.178) | 11:50 | |
| ryukazou | https://github.com/Vladimir-csp/uwsm | 11:52 |
|---|---|---|
| ryukazou | Maybe this could work with machine doesn’t have working suspend and resume | 11:53 |
| mesaoptimizer | what is the status of the MNT Pocket Reform wifi connectivity? Say I order a Pocket Reform now, and once I get it, I flash it with Arch. What can I expect? I understand that there were (and maybe still are?) issues with wifi connectivity with some Pocket Reforms, but am unsure if this also extends to the new wifi cards | 11:59 |
| mesaoptimizer | I mean I guess I could use an external tiny wifi dongle in the worst case | 11:59 |
| mesaoptimizer | still kinda sucks if the wifi card is unreliable | 12:00 |
| ryukazou | AsiaRF card from MNT Shop is reported working fine with Debian, so I don’t think it would be that difficult to make it work on arch. | 12:03 |
| ch | the asiarf card has normal driver support, that works | 12:04 |
| ryukazou | You might need to build your own kernel though if no one supplied it in the AUR | 12:04 |
| ryukazou | ch: THAT IS WONDERFUL | 12:04 |
| ch | afaik if you order a new pocket, you cant even get the old cpu module with the problematic wifi anymore | 12:04 |
| * andypiper -> andypiper[afk] | 12:04 | |
| - andypiper[afk] (QUIT: Quit: My device has gone to sleep. Zzzz…) (~andypiper@89.36.117.58) | 12:04 | |
| mesaoptimizer | so no patched kernels necessary? | 12:05 |
| mesaoptimizer | in that case that's lovely | 12:05 |
| ch | you still need patches for cpu module and dts | 12:05 |
| mesaoptimizer | oh | 12:05 |
| + erle (~erle@user/erle) | 12:07 | |
| + andypiper (~andypiper@89.36.117.58) | 12:08 | |
| * Asmadeus_ -> Asmadeus | 12:10 | |
| + paperManu (~paperManu@198.16.214.40) | 12:19 | |
| - GNUmoon (QUIT: *.net *.split) (~GNUmoon@gateway/tor-sasl/gnumoon) | 12:28 | |
| - mjw (QUIT: Killed (mercury.libera.chat (Nickname regained by services))) (~mjw@gnu.wildebeest.org) | 12:47 | |
| * Guest823 -> mjw | 12:47 | |
| - andypiper (QUIT: Quit: My device has gone to sleep. Zzzz…) (~andypiper@89.36.117.58) | 12:47 | |
| + andypiper (~andypiper@89.36.117.58) | 12:51 | |
| josch | minute: thank you for clarifying the license of reform-handbook in https://source.mnt.re/reform/reform-handbook/#licenses You also ACK-ed a debian/copyright file that I wrote on the base of that paragraph in the project's README.md. I'm writing you now because you might've forgotten about the non-free (according to DFSG) logo. Your intention is for the logo to be released under CC-BY-NC-4.0 but the logo | 13:00 |
| josch | is part of the handbook and the artwork therein. Thus, maybe that paragraph is not quite accurate? It misses the fact, that one also has to abide by the terms of CC-BY-NC-4.0... :/ | 13:00 |
| josch | minute: or maybe you really meant what you wrote in that paragraph which would of course also be fine and it would allow for the handbook to be uploaded to main | 13:00 |
| josch | minute: i'm just writing you to make sure that no mistakes happen... licenses are always frustrating... | 13:00 |
| + gustav28 (~gustav@c-78-82-38-93.bbcust.telenor.se) | 13:02 | |
| minute | josch: ah damn, you're right about the logo. i misremembered that you removed the logo or sth | 13:09 |
| ch | was gonna say, maybe the logo could be dropped in the debian version? | 13:10 |
| minute | josch: i don't think i can make the logo -SA and still prevent misuse by bad actors / enforce the fact that the mark has to clearly identify electronics made only by us to comply with WEEE | 13:10 |
| minute | ch: but then it would also be quite meh to ship that with the devices | 13:10 |
| minute | so i think i'll add an exception for the MNT mark and make that CC-BY-NC-4.0 | 13:10 |
| minute | then it can be non-free at least, right? | 13:11 |
| ch | :-\ | 13:11 |
| josch | CC-BY-NC-4.0 can be non-free, yes | 13:11 |
| minute | the problem is that we will get in trouble with customs and regulatory bodies if other people put our brand on products | 13:11 |
| ch | i guess for branding purposes there'll always be a need for some mnt-only packages | 13:12 |
| minute | yeah | 13:12 |
| ch | (grml has the same problem, even if its just software) | 13:12 |
| josch | then maybe i work on a reform-branding package first? | 13:12 |
| josch | that package can include logos and fonts | 13:12 |
| minute | josch: also not bad | 13:12 |
| josch | if i make this a build-time dependency which embeds the logo in the right places, maybe a reform-handbook (for non-free, that's the package for the MNT system images) and a reform-handbook-free package for main (that's what i can put on reform.d.n) could be a good solution? | 13:14 |
| josch | since the output of reform-handbook is a pdf, i don't think the logo can be embedded at run-time | 13:15 |
| minute | josch: yeah, sounds good | 13:15 |
| minute | here's the brand registration btw ^^ https://register.dpma.de/DPMAregister/marke/register/3020202154143/DE | 13:17 |
| josch | minute: in the handbook, i think the prominent pages are the cover page and the last page. It's easy to leave them out. Do you care about the logo that is embedded in the screenshots in the upper-left-hand corner? | 13:18 |
| minute | josch: i don't care about the embedded logo. i think that can be "fair use" | 13:18 |
| josch | okay, then i'll just remove the big ones at the front and end of the handbook | 13:19 |
| josch | minute: thank you for your patience with that | 13:19 |
| minute | josch: i have to thank! | 13:20 |
| josch | you are welcome :) | 13:21 |
| - Ar|stote|is (QUIT: Ping timeout: 252 seconds) (~linx@149.210.17.178) | 13:22 | |
| + Ar|stote|is (~linx@149.210.17.105) | 13:27 | |
| + mrbcmorris_ (~mrbcmorri@1513413-static.lxtnkya3.metronetinc.net) | 13:43 | |
| - mrbcmorris (QUIT: Ping timeout: 265 seconds) (~mrbcmorri@user/mrbcmorris) | 13:45 | |
| minute | 350x of the alternative model pocket reform displays arrived | 13:48 |
| grimmware | fingers crossed | 13:49 |
| josch | i just had this idea: the reform-branding package (in non-free) could take the PDF built by reform-handbook (in main) and slap one page to the front and one page to the back and publish that as another package which can then live in non-free | 13:50 |
| josch | ch: does that sound like a good idea to you as well or do you have something else in mind? | 13:50 |
| ch | i was thinking the nonfree package could use the free package to run a new build with additional inputs, but this also seems fine | 13:51 |
| josch | ch: in your version, the package in main would have to create a reform-handbook-source binary package so that the reform-branding package has access to the source, no? | 13:51 |
| ch | yeah, that would suck indeed | 13:52 |
| josch | since Lukas says they don't care about the small embedded MNT logos in the screenshots, i think just slapping cover front and back to it in the non-free package is what i'll do... | 13:53 |
| minute | wait, sorry i realized now this is only about the front + back cover? | 13:55 |
| minute | we can just remove those entirely... i thought this was about the logo on the top left corner in the html version | 13:55 |
| josch | minute: for the html version, i can strip out the logo at run-time as that is just a path in the filesystem | 13:55 |
| josch | then those who do the reform-branding package installed would see the logo in the html version and those who do not would not see it | 13:56 |
| josch | (maybe even via some javascript or something) | 13:56 |
| minute | josch: great. and we can just leave out the front+back pages in general in the pdf version | 13:56 |
| josch | oh | 13:56 |
| minute | it's not necessary | 13:56 |
| josch | okay, if you are fine with that, then we can do this | 13:56 |
| minute | there's also a blank page in front of the TOC that can go | 13:57 |
| josch | right, without the cover, that page makes no sense anymore | 13:57 |
| minute | (but doesn't need to if that's complicated) | 13:57 |
| josch | no, that's easy :) | 13:57 |
| josch | aha, the background image CSS property supports a list of url(), so i can just first put the non-free version (displayed if you have reform-branding installed) and then list the placeholder image second :) | 14:09 |
| + chomwitt (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 14:11 | |
| minute | josch: neat! | 14:16 |
| - paperManu (QUIT: Ping timeout: 272 seconds) (~paperManu@198.16.214.40) | 14:32 | |
| + paperManu (~paperManu@159.203.28.24) | 14:32 | |
| minute | ok, tested the first of the alternative displays for pocket and it's really good phew | 14:55 |
| minute | now i just need to do/finish the driver integration work to be able to use both displays | 14:55 |
| - chomwitt (QUIT: Ping timeout: 276 seconds) (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 15:07 | |
| + chomwitt (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 15:20 | |
| grimmware | \o/ | 15:25 |
| grimmware | I've just had a revelation about my keyboard lock-ups by the way. They are very much coincident with sysctl timeouts and I think that's related to the fact that I have a systemd service that tails /dev/ttyACM0 so I can multiplex out processes that are reading from the sysctl. I have a theory that when the sysctl does its more *occasional* timeouts as it is liable to do whilst I'm using a modified prerelease, trying to tail | 15:31 |
| grimmware | the uart too quickly is causing the sysctl to get stuck in a restart loop or similar which is making the keyboard do weird things | 15:31 |
| grimmware | I'm going to run without my systemd unit for a while and see what happens but that basically means I can't use my lid-closed detection :/ | 15:32 |
| grimmware | or at least not when it's plugged in because that seems to be the thing that triggers it | 15:32 |
| + mark_ (~mjw@gnu.wildebeest.org) | 15:33 | |
| andypiper | I wonder if there is a more async way to handle that rather than tailing /dev/ttyACM0 | 15:33 |
| grimmware | This could also be related to the way I'm reading the accelerometers screwing with the timeouts on the PD code | 15:33 |
| grimmware | andypiper: I was wondering if it would be possible to get the sysctl to proxy the i2c directly instead | 15:34 |
| andypiper | reminds me that I have a couple of the LIS3DH boards sitting in bags on one side of my desk and haven't gotten around to that mod yet | 15:35 |
| grimmware | andypiper: lmk if you start working on it, I've got an updated branch for the sysctl (post refactor) and most of the userland code in place now | 15:39 |
| grimmware | my advice would be to hold fire until I figure some of these bugs out | 15:39 |
| andypiper | ooh! thanks - unlikely to have time until after our studio art show (post-Nov 18), but good to know! | 15:39 |
| grimmware | ah nice I might have some more answers by then | 15:41 |
| grimmware | ah, looks like the lpc driver in the kernel talks to the sysctl over spi | 15:53 |
| grimmware | so actually it probably makes more sense for me to patch *that* to be able to present an interface under /sys (if there isn't one already) and use that to send requests for accelerometer data | 15:55 |
| grimmware | minute: does that make sense to you? ^ | 15:55 |
| grimmware | yeah, looks like I should be able to use `lpcCommand`, the only difficult bit here is deciding how to make the command available to userland without e.g. spamming dmesg | 16:04 |
| hramrach | event device | 16:07 |
| hramrach | or a file descriptor that can be polled but event devices probably have better infrastructure for this | 16:08 |
| ch | minute: when you do the sysctl fw for the displays let me know. i'm sorry i didn't get further with fwupd and usbids. but the fw for the other displays should have a different revision or something else so updating can work (or at least not break anything) | 16:09 |
| hramrach | /dev/input/event2:Lid Switch | 16:09 |
| grimmware | it's not just a lid switch though, it's also orientation | 16:10 |
| hramrach | IIRC there are accelerometer events as well | 16:10 |
| grimmware | It's a good suggestion at any rate, I'll have a think about it | 16:11 |
| hramrach | ch: there are mutiple ways to make the firmware do a different thing. One is to have different firmware builds. Another is to store configuration in the part of hte flash not used by the firmware. Makes especially sense if whatever hardware has sysctl needs to be different physically as well. Detect the different hardware in the code if such detection is possible. Tell the kernel through device | 16:13 |
| hramrach | tree, and have it send something to the firmware to tell it what to do. | 16:13 |
| hramrach | Also depends on what are the consequences of getting this wrong | 16:13 |
| grimmware | ah looks like I can easily have it spit out in /sys/devices/platform/feb10000.spi/spi_master/spi1/spi1.0/somefile | 16:15 |
| grimmware | I'll prolly do that. | 16:15 |
| ch | hramrach: storing it in flash sounds nice, but then we need a custom update protocol | 16:16 |
| hramrach | ch: it's not a cutom update protocol, it's a custom binary that is bigger | 16:17 |
| ch | what does that help? | 16:17 |
| ch | something has to preserve the flash that is not used as firmware code | 16:18 |
| hramrach | but also you can have the feature to tell the firmware what to do, and save that in the flash memory by the firmware | 16:18 |
| hramrach | tha flash that is not used for code is by default preserved | 16:19 |
| hramrach | eg when flashing new miropython version the interpreter is update and the python code that is stored on the device is preserved | 16:19 |
| ch | is there any sample code showing the setup for that? | 16:22 |
| hramrach | micropythn would be a sample but not trivial one. Also read that thing about sstoring data in flash posted earlier | 16:23 |
| hramrach | thre is no requirement to erase all flash, only enough to store the binary is generally erased, and the rest remains. With that storing data near the end of the memory is pretty reliable unless you are getting closes to filling the whole capacity with code | 16:24 |
| ch | i know there is no requirement, but a) i dont know what the bootrom does b) what the magic is for the linker to leave the space | 16:25 |
| ch | (... and make it addressable somehow) | 16:25 |
| hramrach | it's described in the uf2 protcol somewhere probably | 16:26 |
| hramrach | practically the flash is not fully erased, and the fact is abused by a lot of programs in the wild | 16:27 |
| ch | the uf2 "spec" is useless | 16:27 |
| hramrach | https://www.makermatrix.com/blog/read-and-write-data-with-the-pi-pico-onboard-flash/ | 16:28 |
| hramrach | that the flash memory is used for non-code data by a lot of programs is a fact, though | 16:29 |
| hramrach | the magic is to not make the binary big enough to fill the flash, kind of happens on its own .. until it is too big to fit at all | 16:33 |
| ch | thats, sorry, insane | 16:34 |
| - andypiper (QUIT: Remote host closed the connection) (~andypiper@89.36.117.58) | 16:34 | |
| hramrach | and the flash is always accessible, you can craft a pointer to arbitrary memory location | 16:34 |
| ch | the correct way is to tell the linker that the space is limited | 16:34 |
| ch | and have a symbol exposed by the linker to tell the code where the dedicated area is | 16:34 |
| hramrach | There is a define in the pico libraries for that | 16:35 |
| minute | grimmware: yeah, using the SPI interface is more reliable i think | 16:35 |
| minute | ch: ok, will do! | 16:36 |
| hramrach | I think miropython defines the usable flash memory size to get a fixed start of the flash data but if you use the hack as described in the tutorial and write data from the end then you do not really need that | 16:37 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 16:45 | |
| - mark_ (QUIT: Ping timeout: 246 seconds) (~mjw@gnu.wildebeest.org) | 16:49 | |
| ch | (generally i like the idea of doing it with one firmware. but the details need figuring out, to not cause problems down the road) | 16:54 |
| hramrach | I wanted to do some more testing but reflashing micropython a few time is as far as I got | 16:56 |
| ch | https://vanhunteradams.com/Pico/Bootloader/Bootloader.html has a lot of good info, like pico_set_linker_script and https://github.com/raspberrypi/pico-sdk/blob/1.5.1/src/rp2_common/pico_standard_link/memmap_default.ld | 16:59 |
| hramrach | The latter would be the defines that the flash tutorial uses to access the flash memory | 17:12 |
| ch | yes, but that file should be modified to have a smaller FLASH area, and a new FLASH_SETTINGS (or whatever) area and export a symbol | 17:13 |
| ch | s/export/define/ | 17:13 |
| ch | + an assert in there just in case the code grows too much and/or the linker does sth "interesting" | 17:13 |
| hramrach | no, the file should stay the same, the flash does not go away | 17:13 |
| ch | that flash should never be used by code though | 17:13 |
| ch | and thats what this file defines | 17:13 |
| hramrach | no, that's not what it defines AFAICT. It defines the memory layout regardless of what is used by code | 17:14 |
| ch | no, it literally defines where the linker places code | 17:14 |
| hramrach | if you wanted that check you should check that the resulting binary is not too large | 17:14 |
| ch | (and in addition it also tells the linker where that code will be at runtime) | 17:15 |
| hramrach | yes, and that does not change even if part of the flash memory is used for other purpose, the layout stays the same, the code is loaded at the same place | 17:16 |
| ch | the layout does change, because the linker is not free anymore to put code into the section we'll use for something else | 17:16 |
| - chomwitt (QUIT: Ping timeout: 252 seconds) (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 17:48 | |
| + spew (~spew@201.141.99.170) | 17:48 | |
| + mark_ (~mjw@gnu.wildebeest.org) | 18:26 | |
| - switchy (QUIT: Ping timeout: 264 seconds) (~switchy@mechboards/switchy) | 18:30 | |
| + switchy (~switchy@mechboards/switchy) | 18:32 | |
| + chomwitt (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 18:56 | |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 19:18 | |
| Twodisbetter | minute: or anyone really: any hints on getting wayfire to use brightness control instead of dpms? | 19:24 |
| * mjw -> Guest8797 | 20:14 | |
| - Guest8797 (QUIT: Killed (lithium.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 20:14 | |
| * mark_ -> mjw | 20:14 | |
| + Guest8797 (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 20:14 | |
| grimmware | wow this spi implementation for the accelerometer turned into trying to understand half precision floating points on arm pretty fucking quickly | 20:20 |
| grimmware | gonna have to make sure I understand this given it has to work across arm32 and arm64 :P | 20:22 |
| grimmware | (I need to pack 3 floats into 8 bytes, so I need them half precision) | 20:22 |
| josch | grimmware: if you do that manually, and if your floats share a similar magnitude, consider letting them share the exponent, then you only need to store the mantissa | 20:25 |
| grimmware | josch: I'm going to try to let the compiler do it for me as there appears to be a type supported by both architectures | 20:34 |
| josch | ah nice | 20:37 |
| grimmware | lol, trying to in-band a "read failed" value given I have to pack 3 values (separately read) at once | 20:49 |
| grimmware | have just written the best comment of my coding career so far | 20:49 |
| grimmware | /* Would definitely kill you, will use as "read failed" */ | 20:50 |
| grimmware | (in reference to the number of Gs you can express with the highest magnitude signed 16 bit float) | 20:50 |
| minute | hehe | 21:20 |
| hramrach | you can also send NaNs | 21:28 |
| + chomwitt (~chomwitt@2a02:587:7a12:1b00:1ac0:4dff:fedb:a3f1) | 21:41 | |
| grimmware | dammit | 21:47 |
| grimmware | hramrach: yeah just figured that out because I realised I had to pack as two uint8_ts anyway | 21:48 |
| grimmware | so I checked what all bits set was and turns out yeah it's NaN | 21:48 |
| grimmware | which is more technically correct :( | 21:48 |
| grimmware | lol turns out the sensor is returning 16 bit values anyway and the example code I cribbed from was using full floats | 22:10 |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-38-93.bbcust.telenor.se) | 22:15 | |
| grimmware | okay, I think I've done the sysctl side of things, time to stop for the evening and I guess I'll take a stab at the lpc kernel driver tomorrow | 22:23 |
| - jacobk (QUIT: Ping timeout: 276 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 22:36 | |
| jfred | huh... mate desktop has a wayland version now. I wonder if that would run on the reform... | 22:40 |
| jfred | and mate-netbook is still packaged in debian and guix. could give the pocket reform a netbook-style UI :) | 22:41 |
| minute | debian's mate-desktop-environment seems to be at version 1.26, but 1.28 was released in february... | 22:45 |
| minute | 1.26 is from 2021 oof | 22:45 |
| minute | ah i did not realize that mate is a continuation of the gnome 2 desktop idea. neat | 22:46 |
| josch | there is also cinnemon from the same group of developers | 22:47 |
| josch | though i recently opted for installing gnome flashback on a friend's computer instead | 22:47 |
| minute | oh ok... so 3 options for that kind of experience? | 22:48 |
| josch | i usually get some live isos and let people try out all the options -- i lost track of which option is the best maintained or most active one... | 22:51 |
| minute | interesting | 22:53 |
| minute | so you let them do a bit of UX testing and see what they like most? | 22:54 |
| josch | yes, using grub-mkrescue it's easy to make a bootable live usb-stick and then in the grub onfig on that stick one can write loops like "for isofile in /boot/iso/debian-live-*-amd64-*.iso; do ..." and that will make all isos you dump into /boot/iso/ selectable via the grub menu and lets you boot and try everything via a single medium | 22:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!