<clever> samueldr: i see a dedicated hardware block for jpeg, but nothing that looks 3d related, though i have observed that the 4 byte id code isnt visible if a block is powered down
<clever> one of the pages that was scrapped from patents claims `The GPU can hardware decode H264, MPEG1/2/4, VC1, AVS, MJPG at 1080p30`
<clever> As far as I'm aware the 2 cores are identical. There is only 1 vector register file, so all vector code uses mutexes in the default firmware.
<clever> samueldr: ahh, so there is no point in trying to do vector stuff on both cores
<clever> ahh, each core has its own 64x64 reg file, but they share the vector unit that does the actual operation
<clever> s
<clever> vc4-regs.h:#define TARGET_BAUD_RATE 115200
<clever> samueldr: ok, interesting, the source says the baud rate is 115200
<clever> but the scope says the baud is ~9000
<clever> it should be ~13 times faster
<clever> vc4-init-sim.c: MMIO_WRITE (AUX_MU_BAUD_REG, SYSTEM_CLOCK / (TARGET_BAUD_RATE * 8) - 1);
<clever> vc4-regs.h:#define SYSTEM_CLOCK 250000000
<clever> aha, and there is a comment, to change the SYSTEM_CLOCK
<clever> vc4-regs.h://#define SYSTEM_CLOCK 19200000
<clever> which is ~13x
h0m1 has quit [Ping timeout: 250 seconds]
h0m1 has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 240 seconds]
* craige[m] has some reading back to do :-)
nbp has quit [Ping timeout: 244 seconds]
nbp has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
ris has quit [Ping timeout: 258 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-aarch64
<andi-> samueldr: is there support for the nexus 5x on nixos-mobile? I just inherited two of those devices from family members.. I experiment with them / ship them somewhere if you think that is valuable (and not just wasting your time ;))
sigtrm_ has joined #nixos-aarch64
Willi_Butz has joined #nixos-aarch64
orivej has joined #nixos-aarch64
WilliButz has quit [Ping timeout: 265 seconds]
sigtrm has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
ris has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
Willi_Butz is now known as WilliButz
orivej has joined #nixos-aarch64
<samueldr> andi-: not currently, but they should work fine, as they are aarch64
<samueldr> they are limited in RAM (2GB), but still in the acceptable range I think
<andi-> I'll try to get them running tonight. Hopefully won't be that much of a disaster.
<clever> samueldr: i forgot i had these docs up, have you seen the openmax IL stuff before? https://ext.earthtools.ca/docs/
<samueldr> I don't think so, clever
<samueldr> andi-: there may be disaster in the docs department to get you started :)
<clever> samueldr: basically, you can use api's on the rpi to spawn an instance of those components, and then link the ports of matching color between them
<andi-> samueldr: ha, there is code! No need for docs.
<samueldr> andi-: if only that was true :D
<clever> samueldr: so you could spawn a read_media, video_decode, video_render, audio_decode, and audio_render, wire them all up, and shove a raw .mkv file into the input
<samueldr> andi-: the issue is the configuration, not the code
<clever> samueldr: and boom, you have a fully working hw accellerated video player
<samueldr> clever: that explains the OMX stuff in software
<andi-> samueldr: worst case I'll bug you until it works :p
<clever> samueldr: yep, thats the other name, forgot it till now
<samueldr> though you may need to also run a fastboot command to enable the UART
<clever> samueldr: the links between each component are formed by an array of fixed size buffers, with a list of empty buffers, and a fifo of buffers of data
<samueldr> basically, the nexus and pixel family are great for that reason, they do have UART accesss
<clever> samueldr: and you can also create compatible components in userland on the arm side, such as a file source, that emits data from a .mkv file
<clever> samueldr: the thing on more fuzzy on, and is probably getting into NDA territory, is how much of those things is handled in hardware, and how much is just vector ops in the VC4
<clever> s/on/i'm/
<samueldr> andi-: you will also have to make a choice of which kernel to port, mainline or OEM, in the end both should be ported, mainline to continue its improvement, and OEM to have everything work
<clever> samueldr: there are also modules like camera, which strangely has 2 output ports, and an enable flag for each
<samueldr> clever: that way you can do funky stuff I guess?
<clever> samueldr: one is meant for video preview, while the other for capture
<samueldr> yeah, makes sense
<clever> samueldr: but it also has a video splitter module, that could have done the same thing
<samueldr> unless the preview/capture has differences
<samueldr> like how on android previews are of lesser quality
<clever> `Due to limitations in the current underlying layers, it is not currently possible to emit the same frame at multiple resolutions. This means that to obtain both preview and video capture images simultaneously, the two ports must be at the same resolution and of the same image format.`
<samueldr> haha, looks like the intention was ther
<clever> yeah, lol
<clever> it also has a 3rd port for still images
<clever> which produces the raw image, before debayer filters are applied
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> now that there are cheap~ish FPGAs, like 5$ FPGAs, I wonder what is the minimum requirements to have one simulating an SD card while doing some magic on the other side to talk to a computer
<gchristensen> sounds nice
<gchristensen> maybe #sparkfun has some ideas
<clever> samueldr: i suspect an AVR might even be able to do that
<clever> might have lower data rates though
<samueldr> yeah, that's the thing :)
<samueldr> though not sure it could really... it looks like no one does SD emulation
<samueldr> the best I found is just switching the sd cards around
<gchristensen> might be a much easier, if bodgier version
<samueldr> sure would be
<samueldr> but you still have the drawbacks of SD cards being not good :|
<gchristensen> yeah
<clever> https://www.sparkfun.com/products/12941 full size sd socket breakout
<clever> https://www.sparkfun.com/products/11468 full size sd card sniffer
<gchristensen> the bodgier solution I mean, though, is to have a breakout and switch to toggle between which host is talking to the card at a time
<samueldr> that's exactly what the SD_MUX is
<gchristensen> ahhh
<gchristensen> oops :)
<samueldr> but controlled via the computer
<clever> samueldr: what where you thinking of?
<samueldr> something that does the actual SD protocol and talks to... something else than SD
<samueldr> the "something else" is vague since it could be anything
<clever> samueldr: but why? :D
<samueldr> run tests!
<samueldr> imagine sending a real deal nixos sd_image to a raspi
<gchristensen> for example you might want a usb-to-sd card
<samueldr> via network
<gchristensen> wher ethe usb is plugged in to the computer and the sd card end is pretending to be an sd card
<gchristensen> ?
<clever> samueldr: have you seen the mass-storage stuff in the compute module?
<samueldr> sure
<samueldr> but that's not the same thing
<samueldr> and not all devices support that
<clever> samueldr: basically, you can turn the entire rpi into a usb stick, then use that to flash its own SD card
<clever> ah
<samueldr> there are some phones with SD card support, also
<samueldr> and the turnaround is going to be worse if it has to flash the sd card first, then run on a real sd card
<samueldr> and ideally, no actual sd card should be in play :)
<clever> yeah
<clever> that reminds me, of the san_boot stuff in ipxe
<samueldr> *thinking*
<clever> it replaces the legacy bios routines to access the local hdd
<clever> and will re-route all hdd access over iscsi
<samueldr> the most self-contained PoC would still have a big issue: interfacing with enough ram
<clever> so dumb OS's like dos (and grub) think a regular hdd is present
<samueldr> IIRC interfacing with a greater amount of ram is not trivial
<clever> samueldr: you have 2 choices there, a: get an fpga with dram support
<clever> b: just relay all commands to a host pc over usb, and read from the fs
<samueldr> yeah
<samueldr> that was what I was going to say
<samueldr> leave a computer deal with all that
<clever> i also have an fpga here
<samueldr> also, you can trace what's happening
<samueldr> so you can have a block-level diagnosis of what the device is doing with the SD card
<clever> but, in some cases, you can get more
<clever> if i network boot the rpi, i can see more then just what blocks its looking for
<clever> i can see what filenames its looking for!
<clever> which reveals un-documented features
<samueldr> yeah, but I don't care about network boot, here it's about SD card :)
<clever> i got a https://www.sparkfun.com/products/retired/11953 a few years ago
<clever> the chip supports DDR/DDR2/DDR3/LPDDR
<clever> but connecting it over 0.1" headers likely wont go well :P
<samueldr> I'm thinking that FPGA+raspberrypi (0?) could make the thing self-contained enough, and even handle read/write off of network shares
<gchristensen> sounds cool
<clever> samueldr: you just gave me another idea, more hacky, but potentially even faster
<samueldr> don't bit bang usb
<clever> samueldr: how does the rpi4 get usb 3.0?
<gchristensen> lmao
<samueldr> how does it get usb 3.0?
<samueldr> not sure I follow
<clever> samueldr: the rpi4 has a full pcie lane on the cpu, with a pcie->usb3.0 controller
<samueldr> yes
<clever> samueldr: if i rip off the usb3 chip, and shove in an fpga....
<clever> then i could either
<samueldr> sure, but then you're in the fiddly bits of making something new
<clever> a: have the fpga dma the rpi's ram, so the SD card lives directly in host ram
<samueldr> with hardware that wasn't meant for that
<clever> b: add more ram to the fpga, and then the rpi will treat it like a gpu with 8gig of ram
<samueldr> IIRC, PCIe on the rpi4 has the same issue as RK3399
<samueldr> only 32MB of BAR
<samueldr> something about not being able to use more than 32MB of address space AFAIUI
<clever> i think the BAR is only to configure the pci device itself
<clever> which is only a limit if you want many pci devices
<samueldr> yeah, the actual use of that eludes me
<samueldr> but that apparently makes it impossible to use GPUs
<clever> the BAR is how you tell the pci device what physical address its things map to
<clever> i think that limit was also a software thing in the kernel
<samueldr> not for RK3399
<samueldr> and likely not for rpi4 if I understand things right
<clever> now i'm leaning back towards an older project idea i had
<clever> what if you just skip the rpi?
<clever> an ethernet connected fpga?
<samueldr> sure, could work, but that needs more power from the FPGA :)
<samueldr> the main idea here is to deal with the absolute minimum since cheap-o FPGAs are likely to have fewer uh... thingies... to program
<clever> 100mbit is trivial to implement, ive researched that before
<clever> gigabit may be a bit more complex
<clever> ah, cell counts, yeah
<clever> tftp is pretty simple though
<clever> yeah, you could just use tftp to write to the ram, and your done
<clever> samueldr: you may also want to look into https://clash-lang.org
<clever> and they have a #clash-lang
<gchristensen> tftp .... nobody has time for tftp
<clever> gchristensen: you could also just make your own custom udp based protocol :P
<samueldr> hmmm
<samueldr> the FPGA could be too slow
<clever> samueldr: 100mbit needs a 200mhz clock to tx data, and maybe a bit faster for rx
<samueldr> the FPGA I linked to has a 24Mhz clock
<clever> gigabit generally has a deser on the mii
<samueldr> so it's not fast enough for Default Speed SD
<clever> so it doesnt need as extreme of a clock
<clever> oh, lol
<samueldr> though, that's like the cheapest thing
<samueldr> so I figure that something a bit more upmarket could handle it
<clever> the old mojo i linked, can go up to 1080mhz i think
<samueldr> and looks like SD is nice enough to support both 3.3V and 1.8V
<samueldr> neat, 50Mhz could be fast enough with DDR50, if I read correctly somewhere else, it means that we provide data in parallel using multiple pins
<clever> also, the rpi has 2 mmc controllers
<clever> a slower and a faster one
<clever> the bootrom and bootcode.bin use the slower one, because it has a much simpler api
<samueldr> forget about the raspberry pi :)
<clever> you must implement both, if you want the pi to boot from this device
<samueldr> while it is one of the targets, I'd like the idea to work anywhere an SD card works
<clever> compatability with both
<samueldr> hmmm, I'm wrong, SDR vs. DDR is something else
<samueldr> and not sure if a 50Mhz FPGA can handle DDR
<clever> yeah, SDR50 and DDR50 have the same 50MB/sec, but one is 100mhz, the other is 50mhz
<clever> This section describes the available logic resources connected to the I/O interfaces. All inputs and outputs can be configured
<clever> as either combinatorial or registered. Double data rate (DDR) is supported by all inputs and outputs.
<samueldr> though look at how SDR50 is 100mhz, DDR50 is 50mhz
<clever> from the mojo datasheet (several year old fpga)
<samueldr> ah
<clever> DDR50 is just emiting data on the rising and falling edge of the clock
<samueldr> yeah
<clever> so the clock rate is halved, but the data rate is double the clock
<samueldr> but I thought you had to *implement* DDR and not simply configure DDR
<samueldr> if it's configured, then it's likely not much of an issue
<clever> likely depends on the chip, the spartan 6 has it in hardware
<samueldr> yeah
<samueldr> SD requires 8 pins, one for VSS, one for GND, so looks like 6 pins for the actual smarts
<clever> the spartan6 also has hardware serder
<clever> so you just shove a parallel bus at it, and the hardware clocks it out for you
<clever> samueldr: some micro cards have extra contacts, to go even faster
<samueldr> yeah
<samueldr> you need the right hw to read it though
<samueldr> and then there's SD Express
<samueldr> that's just... sick
<samueldr> in both ways
<clever> lol
<samueldr> >> Hosts which implement version 7.0 of the spec allow SD Cards to do direct memory access
<clever> wait, nvme/pcie, what
<samueldr> yes
<samueldr> I said: sick
<clever> i bet the NSA are already drooling over it :P
<samueldr> good thing almost nothing goes over UHS-1
<clever> they cant wait for more devices to adopt that spec!!
<clever> oh yeah
<clever> you can get sd cards, with built in wifi
<clever> its meant to upload your photos to the cloud automatically
<clever> if you could reprogram it, to run in reverse
<clever> https://en.wikipedia.org/wiki/SD_card#Transfer_modes ah, theres the juicy details!
<clever> `The SPI bus mode and one-bit SD bus mode are mandatory for all SD families`
<clever> the AVR supports SPI, so it could deal with the 25mhz possibly
* clever checks specs
<clever> ah, dang, the spi clock must be just under half the system clock
<clever> so 10mhz if you arent seriously overclocking stuff
<clever> When the SPI is configured as Slave, the SPI is only guaranteed to work at fosc/4
<clever> or lower
<clever> or worse!
<clever> SPI bus mode: Serial Peripheral Interface Bus is primarily used by embedded microcontrollers. This bus type supports only a 3.3-volt interface. This is the only bus type that does not require a host license.[citation needed]
<clever> samueldr: you may need to pay a fee if you want to go any faster, lol
<clever> spi mode only uses 4 pins, chip-select, in, out, clock
<clever> the 4bit mode, has 4 data pins, clock, and a control pin, 6 total
<samueldr> clever: "host" license :)
<samueldr> what if you're making an emulator?
<samueldr> or you could do as the chinese do, call it TF
<clever> TF?
<clever> `Until determining the card's capabilities, the host device should not use a clock speed faster than 400 kHz. `
<clever> sounds like the card can report an upper limit on speed, and the host must respect that
<samueldr> >> The microSD removable miniaturized Secure Digital flash memory cards were originally named T-Flash or TF, abbreviations of TransFlash. TransFlash and microSD cards are functionally identical allowing either to operate in devices made for the other
<clever> so you could go with the weaker FPGA's
<samueldr> sure, but I want speed :D
<clever> ahh, loop-holes!
orivej has quit [Ping timeout: 240 seconds]
<samueldr> hmmm
<clever> samueldr: this table mentions card royalties
<samueldr> not sure if DS and HS could be skipped and only UHS-1
<samueldr> though, looking again at the spec, it would give no real advantage to skip them
<samueldr> other than not implementing them
<clever> samueldr: https://www.sparkfun.com/products/14055 120mhz arm cortex m4 cpu, 256k ram, half an ethernet controller (just needs the mii) full 100mbit, 3 spi ports
<samueldr> I don't know that much about all that
<samueldr> but isn't an FPGA better to let it handle the sync from an external source?
<clever> when configured as an spi slave, the external source provides the clock, so that doesnt matter much
<clever> for the AVR, there is the requirement that the low and high period of the external clock, be at least 2 clock periods for the internal clock
<samueldr> yeah, but implementing SD as SPI is not desired here :)
<samueldr> (and I'm not ordering from sparkfun since they use UPS and UPS charge abusive fees over top of the duties and taxes)
<samueldr> for 28.44 of "government charges" I had to pay 81.33 total
<clever> ouch
<samueldr> in there, only 9.39 of actual duties
<samueldr> well, taxes
<samueldr> and UPS didn't leave me the right to self-declare
<samueldr> they told me that if I don't accept the delivery it's sent back and I *still* owe them
<clever> sounds like that could be abused
<clever> whats your address again? :P
<samueldr> and self-declaring is not an optional thing, it's required by the fact that they can handle the brokerage for you
<samueldr> meanwhile DHL are not abusive
<samueldr> they charged me 11+5 of fees for 40.53$ tax
<samueldr> CPC/USPS are limited to 5$ of additional fees
<samueldr> if you have to order from sparkfun, pick CPC/USPS, it's going to be cheaper in the end :/
tilpner has joined #nixos-aarch64
<samueldr> got u-boot 2019.10 mainline working on the PBP
<samueldr> (no display init yet, though anarsoul has said that's among the things they'll be working on when receiving a PBP)
<samueldr> annoyingly, the reason I had issues was because I was not doing everything required :)
<samueldr> once I read the fine manual I saw the error of my ways
<clever> PBP?
<clever> ah
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
<samueldr> can't say much about it yet
<samueldr> just verified stuff worked as expected with the shipped image
<samueldr> then erased it
<samueldr> so I could get mainline stuff, and nixos, going
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gchristensen> github.com/ipxe/pipxe
<clever> gchristensen: nice
<samueldr> again something that hogs the sd card :( (raspberry pi's fault)
<clever> samueldr: it may be possible to do that without a card, using the official netboot stuff
<samueldr> probably
<samueldr> though seems redundant :)
<samueldr> serve a program to then serve a program
<clever> yeah
<gchristensen> ideally over tftp for maximal misery
<clever> i seriously suspect the broadcom tftp client doesnt do checksums
<clever> i get random crashing when i netboot
<samueldr> oh, pipxe is built using EDK2, nice
<gchristensen> not to mention tftp is terrible
<clever> something i'm curious about, is chainloading start.elf
<clever> and can i convince the rpi foundation to make a start.elf that doesnt touch the arm bootstrap
<clever> basically, i want to make the bootup more normal
<clever> the VC4 should only load linux, and nothing more
<clever> and then linux will optionally provide a copy of start.elf
<clever> samueldr: another benefit of the above, if you arent forced to load a 2mb start.elf, maybe you could fit it on the spi flash??
<samueldr> "fdt_find_or_add_subnode: chosen: FDT_ERR_BADSTRUCTURE"
<samueldr> looks like that ramdisk is not overstepping on top of fdt, so likely not that
<samueldr> (anyways gets loaded after the ramdisk)
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 245 seconds]
FRidh has quit [Quit: Konversation terminated!]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<craige> THanks for all those notes, clever, samueldr - I'll expect to have >= ~2 hours a week to apply to this, so it;s going to be really slow going now I'm back home (which is why I put in so many hours whilst in Brno). I flashed the blueline to LineageOS jsut to successfully get another OS running :-) Tried a couple more kernel builds but still didn't get FB love but the kernel wasn't crashing,
<craige> which was something. Hoping to avoid the serial cable but may have to go down that road :-)
<samueldr> craige: by the 7th I should be able to tell you it works or not
<samueldr> and if it works, it's literally plug and play
<samueldr> not even soldering
<craige> :-D
<clever> samueldr: something i wonder, which is easyer to get working, framebuffer or usb gadget?
<samueldr> without a way to know why gadget fails, gadget will be amazingly hard to fix
<samueldr> which is why serial is important to me
<samueldr> once I get gadget going on pixel 2, I believe pixel 3 should fall squarely in place
<samueldr> framebuffer, no idea
<clever> mainly thinking, if the usb controller is one that worked before
<samueldr> literally none
<clever> you could just blindly enable it, and see what happens
<samueldr> yes
<samueldr> it crashes the device
<samueldr> for pixel 2 :)
<clever> then you can get serial over usb gadget
<clever> or full network
<samueldr> I know
<samueldr> that's how I access the device
<samueldr> via network
<samueldr> when it works
<samueldr> so yeah
<samueldr> plug and play as in this kind of serial device
<clever> oh, remember netcon?
<samueldr> clever: yeah
<samueldr> clever: though not as useful over rndis
<samueldr> happens too late
<samueldr> oops
<samueldr> not the right one
<samueldr> this one
<samueldr> (will require a type-c cable
<clever> was thinking, if you make the framebuffer a kernel module
<clever> then you can load it later on purpose
<samueldr> the latter one has female and mail type-c
<samueldr> so pass-through and ADB may work
Ox4A6F has quit [*.net *.split]
Ox4A6F has joined #nixos-aarch64
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
LnL has joined #nixos-aarch64
tilpner has quit [Quit: tilpner]
orivej has joined #nixos-aarch64
<samueldr> ugh... I hate myself some days
<samueldr> I apparently typoed the baud rate in my rockchip serial wrapper script
<samueldr> I was off by one order of magnitude too much
<clever> samueldr: i tend to be paranoid with serial ports, and slap a scope on them to confirm the baud rate
<samueldr> lol
<samueldr> now it just works
<samueldr> spent a while going through all my serial adapters
<samueldr> none would work
<samueldr> well that's explained now
<clever> when the cpu freq for the vc4 was off, 4800 and 9600 read data, but it was garbage
<clever> a scope found the baud rate was 9000
<clever> 13.020833333333334
<clever> > 250 / 19.2
<{^_^}> 13.0208
<samueldr> yeah, I wasn't even getting garbage
<clever> > 115200 / 9000
<clever> 12.8
<{^_^}> 12
<samueldr> - exec ${picocom}/bin/picocom -b 15000000 "$@"
<samueldr> + exec ${picocom}/bin/picocom -b 1500000 "$@"
<clever> the ratio of freq to baud matches up perfectly
<clever> that will also do it, lol
<samueldr> too many zeroes
zmacs has joined #nixos-aarch64
<samueldr> 115200 is easier to grok
<clever> i dont know how, but 115200 just comes naturally, lol
<samueldr> well, a pair, 52 another pair
<samueldr> you know it won't be a pair of zeroes first
<samueldr> so 11 52 00
<samueldr> at least, that's how it feels for me
<samueldr> though, now I can gladly test nixos with their BSP u-boot
<samueldr> mainline u-boot, in the end, fails to do *something* with the device trees
<samueldr> even when using their image
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
<samueldr> oops, the keyboard of the PBP has a nasty key rollover issue :(
<samueldr> holding LCTRL+LSHIFT the TAB key will not work... so no way to cycle back your tabs
<clever> ouch
<samueldr> in addition to multiple other similar issues on the letter matrices
<samueldr> though letter matrices are more excusable
<clever> ive only rarely had issues like that
<clever> typically if i'm trying to walk (hold w) while hitting 3 or 4 other modifiers and hotkeys at once
<samueldr> yeah, same
<clever> i multi-task too hard :P
<craige> exit
<samueldr> just tested my keyboard here and it has 6-keys rollover
<samueldr> goodbye craige
<craige> heh ww :-)
<samueldr> or uh, good mornin
<samueldr> and it's any 6 keys
<samueldr> the PBP keyboard really has issues with matrices
<samueldr> holding Q and A makes the whole two rows unusable
<samueldr> only the letter rows though
<samueldr> it's likely unfixable, and a hardware issue :(
<clever> hmmm, weird, if i hold q, then tap w, q stops repeating
<clever> same for q->a
<samueldr> yeah, that's normal
<clever> may need something more then xterm to test that
<samueldr> yeah
<clever> it interupts repeat
<clever> oh, but if i keep holding q+w, can it detect e...
<clever> yeah, q+w+e doesnt detect the e
<clever> but q+a+z works
<clever> so i have similar row issues
<samueldr> yeah, not unheard of, and when done right, invisible mostly
<samueldr> but CTRL+SHIFT+TAB is not invisible :)
<clever> qwr works though
<clever> if i was making a keyboard matrix, i wouldnt include modifiers in the matrix
<clever> make them all dedicated
<clever> another factor is the usb HID layer
<samueldr> definitely not HID here :)
<clever> i think it has 2 modes, either a fixed-size array, that has the scancodes currently held (sets a cap on held keys)
<clever> or press+release events
<clever> samueldr: oh, ive also played with the mpr121 before...
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
<clever> its a 12 element cap-touch sense IC
<clever> i last used it before devicetree had fully taken over
<clever> so i had to write a custom platform driver, that spawns an instance of it, and configures the element->key mappings
<clever> i wanted to add DT support, but the rpi didnt boot with DT at the time, so that wasnt easy to actually test
orivej has quit [Ping timeout: 240 seconds]
<samueldr> xkeycaps (not in nixpkgs) is nice to test
<clever> readkeys and xev are also test tools for it
<samueldr> yeah, though xkeycaps has the keyboard in its gui
<samueldr> so it's obvious while xev you need to think
<samueldr> I paid for a computer to think in my place!
<clever> yeah, that sounds much better
<clever> readkeys is also much lower level, non-x
<clever> and it hijacks the input device, so X cant get events
<clever> oh, evtest is another one
<clever> evtest even works on sound cads
<clever> cards*
<samueldr> IIRC, jack presence
<clever> exactly
<clever> $ nix-build -A qt59.qtwebengine -Q --option builders ''
<clever> builder for '/nix/store/fvg1djd9j2zfw22rmdz6m698jfsph6as-qtwebengine-5.9.7.drv' failed with exit code 1; last 10 log lines:
<clever> applying patch /nix/store/v43m6ldid8561n9q5zxa5rw97jhb6d35-fix-build-with-pulseaudio-13.0.patch
<clever> 1 out of 1 hunk FAILED -- saving rejects to file src/core/config/linux.pri.rej
<clever> ack!, now i cant update half my machines, lol