channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=11&d=11
02:49:00 <klys_> having significantly less free time means I may be looking for something like littlekernel but with acpica and hoping someone else may have developed it.
03:01:00 <vin> Is there a way to introduce fixed latencies to your stores and loads?
03:03:00 <klys_> presumably you're using paging? does the latency include time for a page fault?
03:03:00 <kazinsal> as in, make each load always take exactly X ms?
03:04:00 <kazinsal> or I guess us or ns
03:05:00 <vin> No add X us to loads and stores
03:05:00 <Mutabah> For what purpose?
03:06:00 <vin> Mutabah: this is to mimic RDMA calls
03:08:00 <vin> so I need my stores and loads to be slower than actual
03:08:00 <Mutabah> But why?
03:09:00 <Mutabah> (Short of disabling caching on a region of memory, I don't know of any way of changing access latency)
03:09:00 <Mutabah> But maybe you don't need to?
03:12:00 <vin> I don't have ready access to RDMA so I want to emulate it.
03:12:00 <Mutabah> But why does the timing matter?
03:14:00 <klys_> what's rdma?
03:14:00 <kazinsal> remote direct memory access
03:14:00 <kazinsal> tech for zero-copy networking
03:14:00 <Mutabah> Ah, wait, you want to profile with those access costs?
03:16:00 <vin> That's correct Mutabah
03:25:00 <klys_> are there two or three free projects out there with acpica?
03:41:00 <klys_> found tilck somewhere
03:42:00 <klys_> https://github.com/vvaltchev/tilck/tree/master/modules
03:42:00 <bslsk05> github.com: tilck/modules at master · vvaltchev/tilck · GitHub
06:59:00 <geist> klys_: it's pretty easy to work with acpica
06:59:00 <geist> could fairly easily port it to LK
06:59:00 <geist> what are you looking to do with it?
06:59:00 <geist> i was just thinking about tossing together a acpi lite library, just enough to parse the trivial tables (ones not involving bytecode interpretation)
07:00:00 <kazinsal> yeah, that's be handy for a lot of folks to get a leg up
07:00:00 <geist> but, we had acpica in zircon for a long time, and i remember it wasn't hard at all to port. just have to provide some stub routines for locks and whatnot and bobs your uncle
07:00:00 <kazinsal> because while it's good to know that kind of stuff, ACPI is just... a pain
07:01:00 <geist> yah i started a 'acpi lite' library for zircon a while back, wrote it in C and then it was converted to fancy C++
07:01:00 <geist> but can go into history and grab the C version of it before it was complified
07:01:00 <geist> will add a todo list
07:03:00 <geist> https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/zircon/kernel/lib/acpi_lite/ is the current version of it. if you look back in history there was a simpler one that was basically plain C
07:03:00 <bslsk05> fuchsia.googlesource.com: zircon/kernel/lib/acpi_lite - fuchsia - Git at Google
07:03:00 <geist> but MIT licensed, etc
07:04:00 <geist> https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/zircon/kernel/lib/acpi_lite/include/lib/acpi_lite/structures.h is a lot of the work, to be honest. just typing the stuff in
07:04:00 <bslsk05> fuchsia.googlesource.com: zircon/kernel/lib/acpi_lite/include/lib/acpi_lite/structures.h - fuchsia - Git at Google
07:07:00 <geist> https://fuchsia.googlesource.com/fuchsia/+/645dbffdfbf52f72491187a1c59af1a677e3dd00 actually is the original one. doesn't do much but find the RDSP and whatnot and provide structures to parse some of the simple tables, but thats' actually most of what things need... hmmm!
07:07:00 <bslsk05> fuchsia.googlesource.com: 645dbffdfbf52f72491187a1c59af1a677e3dd00 - fuchsia - Git at Google
07:08:00 <geist> think i might pull this over right now..
07:18:00 <klange> I just want battery status, but that's complicated stuff...
07:18:00 <kazinsal> I think there's some bytecode involved there yeah
07:18:00 <kazinsal> that's one of the really annoying things about ACPI imo. you need to evaluate bytecode for so many little things
07:19:00 <kazinsal> get AC status? bytecode. shut the computer off? bytecode. interrupt routing on the IOAPIC? ooh, you better believe that's a bytcode
07:19:00 <sham1> The fact that one needs the AML for even doing something "simple" like shutting down the computer is silly
07:20:00 <sham1> Although now I'm wondering if one could readily JIT AML
07:20:00 <sham1> Probably not, but it'd be funny
07:21:00 <klange> toaruos will get an AML interpreter eventually...
07:23:00 <klange> random anecdote: should one look at the history of kernel/arch/x86_64/smp.c in my git repo, one will find that it was previously called kernel/arch/x86_64/acpi.c before I said "screw it, I just need the madt and I'm outta here"...
07:29:00 <sham1> Meanwhile I need to deal with a different type of bytecode... I can't even compile this though since this Java I need to study for my work is too darn ancient
07:35:00 <kazinsal> gonna start planning the 64-bit rewrite of my kernel core tonight I think
07:35:00 <kazinsal> I'm now on vacation until the 22nd so I've got plenty of time to fiddle around with osdev stuff
07:47:00 <Ermine> klange: do you plan writing your own interpreter or use acpica
07:53:00 <geist> noice. i got acpi_lite working
07:53:00 <geist> will polish this up and get it in the build
07:54:00 <kazinsal> rad
08:04:00 <geist> it is still written in lightweight C++, but can be converted back to C fairly easily. mostly jsut static casts and whatnot
08:17:00 <geist> there, done: https://github.com/littlekernel/lk/tree/master/lib/acpi_lite
08:17:00 <bslsk05> github.com: lk/lib/acpi_lite at master · littlekernel/lk · GitHub
08:18:00 <geist> basically probes around and finds the ACPI tables and then gives you an ability to iterate over some of the basic ones. more tables can easily be added
08:37:00 <geist> ugh, the MCFG table is described in the PCI Firmware specification
08:37:00 <kazinsal> huh. don't think I've ever actually read that one
08:37:00 <geist> which seems to be behind PCI SIGs password protection
08:38:00 <kazinsal> aaaand that would be why
08:38:00 <geist> it doesn't look complicated, but it basically just has a single entry that says 'yer pcie config table is here'
08:38:00 <geist> looks like it's documented on the osdev wiki, so *shrug*
08:54:00 <geist> easy peasy
08:54:00 <geist> https://www.irccloud.com/pastebin/GWbOJ0Su/
08:54:00 <bslsk05> IRCCloud pastebin | Raw link: https://irccloud.com/pastebin/raw/GWbOJ0Su
19:19:00 <qookie> hi, so i got pcie working on the rpi4 to the point where i can enumerate the devices and access the config space, but trying to access the xhci's bar (after allocating it before) yields an serror
19:19:00 <qookie> does anyone habe any ideas how i can approach this?
19:20:00 <j`ey> it has some quirks, so you should probably look at another OS, to see how it handles it
19:20:00 <clever> qookie: there are 2 traps on the pi4, first is that the ECAM is wonky, and second is the vl805 firmware may be missing
19:21:00 <clever> qookie: do you know if the vl805 eeprom is present or not?
19:21:00 <qookie> clever: yeah i already experienced ecam being wonky (and worked around it by doing the same linux does, not enumerating anything but the first child on the downstream port)
19:22:00 <qookie> i also told the firmware to upload the vl805 fw via the mbox property interface, but i'm not sure if that 100% worked
19:22:00 <clever> i believe that must be done after you assign an address to each BAR
19:23:00 <qookie> that is the case here
19:23:00 <clever> if the vl805 eeprom is present, you can also skip that mailbox call
19:26:00 <clever> qookie: https://imgur.com/Ie6jrA3
19:26:00 <bslsk05> imgur.com: Imgur: The magic of the Internet
19:36:00 <qookie> oh yeah my board has it
19:37:00 <clever> qookie: when you configure the xhci scratch space (as the specs explain), the vl805 will copy its own firmware from flash to host ram, and then begin executing that firmware
19:38:00 <clever> it doesnt have enough ram to hold its own firmware (lol), so it has to steal some host ram
19:38:00 <clever> but then RPF decided to save 25 cents on each board, and just ditch that spi chip
19:38:00 <clever> so some non-standard code has to be side-loaded into the vl805, to make it load firmware that is already in ram
19:39:00 <clever> that spi chip is how the vl805 "just works" when used as a pci-e card on x86, with nothing more then the standard xhci drivers
19:39:00 <qookie> ah
19:39:00 <qookie> well my problem is that i get an serror on the very first read the driver does (reading CAPLENGTH)
19:39:00 <qookie> ig i have to dig through the linux code some more
19:40:00 <clever> yeah, that sounds like you cant even set the scratch space up
19:40:00 <clever> of note, the pci-e controller on the bcm2711, has some inbound and outbound window setup
19:40:00 <clever> which kinda acts like an iommu
19:41:00 <qookie> yeah i do that, but i could've misread the linux driver or made a typo
19:41:00 <qookie> would be nice if i had an actual datasheet and not just the linux code but oh well :^)
19:42:00 <clever> i'm dealing with the exact same issue in the 2d subsystem
19:42:00 <clever> dumping the config that the closed firmware did, reveals it doing things that the linux drivers claim isnt valid
19:45:00 <qookie> typical broadcom :^)
19:46:00 <chibill[m]> I am having issues just getting interrupts xD (on x86) Really need to get some more experience at this stuff. (Also trying to decide if I should transfer into Long Mode before I do anything or not.)
19:49:00 <Bitweasil> chibill[m], unless you've got some explicit reason not to, step 1 ought to be get into long mode, and then step 2, everything else.
19:49:00 <clever> qookie: this is what i'm trying to fix: https://libera.ems.host/_matrix/media/r0/download/matrix.org/GuCehdKPEAwDdRBSXJwbiqiR/20211111_151701.jpg
19:49:00 <Bitweasil> You avoid a LOT of the weird historical complexity that way.
19:54:00 <chibill[m]> I wonder if I can get the multiboot header to drop me into long mode.
19:57:00 <qookie> clever: looks pretty odd and cool at the same time, do you have any clue as to why that happens?
19:58:00 <clever> qookie: well, for one, i wrote a 17bit int into a 16bit field...
19:59:00 <qookie> lol
19:59:00 <chibill[m]> ouch
19:59:00 <clever> capping it doesnt help though
20:00:00 <clever> ok, so when its glitching, the scale factor is 0x9e41 (a 5.16bit fixed-point int)
20:00:00 <clever> 0x9e41 / (1<<16) == 0.6181793212890625
20:00:00 <clever> so the source image is ~61% the size of the output image
20:01:00 <clever> and doing x * 0.61 will give you an x coord within the source image, but it glitches out
20:01:00 <clever> the linux source did say that this mode was only for downscaling, and this is upscaling...
20:02:00 <clever> let me implement the proper upscaling mode...
20:03:00 <chibill[m]> I think I am going to hang out in Protected Mode for now, so I can figure out how to set everything up properly. As I am still figuring out how to set up my IDT.
20:06:00 <chibill[m]> Currently I have a kernel that is basically a lightly modified Bare Bones C Kernel. (I reworked the console output a bit to make it better.)
20:16:00 <Bitweasil> Seems reasonable.
20:17:00 * Bitweasil kind of wants a Frame.Work laptop but has no use for one and shouldn't own modern hardware.
20:34:00 <gog> the spec i want is $2849
20:34:00 <j`ey> I'll take two
20:34:00 <gog> doesn't have a discrete graphics option tho
20:34:00 <gog> that's kindof a dealbreaker for me rn
20:34:00 <gog> also the fact that i don't have $2849
20:35:00 <gog> plus whatever customs makes me pay in tariff
20:35:00 <gog> XD
20:35:00 <j`ey> gog: any luck re: job?
20:35:00 <gog> nothing.
20:35:00 <gog> well, sort of
20:35:00 <gog> it's a part-time store clerk job
20:35:00 <j`ey> better than nothing
20:35:00 <gog> better than nothing and the manager is a cool guy
20:36:00 <j`ey> does the manager need an OS?
20:45:00 <geist> same: re framework laptop
20:46:00 <geist> though i didn't think they went that expensive
20:46:00 <geist> also right now if i got an x86 laptop i'd want a zen based one
20:53:00 <gog> geist: i picked the highest spec plus the 4TB nvme
20:53:00 <gog> but also i agree
20:53:00 <gog> i'd actually like a zen APU
20:53:00 <gog> with actually good integrated graphics unlike intel :p
20:54:00 <gog> also i absolutely do not need 4TB of storage
20:54:00 <gog> it's not like i'm making videos
20:54:00 <gog> unless...
20:55:00 <chibill[m]> I think I got my IDT working, just need to figure out the proper way to configure the PIC and I should be able to test it properly.
20:56:00 <qookie> chibill[m]: why not test it with something like "int 3" or division by zero?
21:15:00 <Bitweasil> ^^
21:15:00 <Bitweasil> You can induce faults that go through the IDT without external interrupts.
21:15:00 <Bitweasil> gog, if I'm going to do anything that requires that much storage, I'll either use externals, or a good desktop. I don't need 4TB on a laptop.
21:16:00 <Bitweasil> And if I *did*, I'd probably be fine with "slow" storage for it.
21:16:00 <Bitweasil> What's the issue with discrete graphics? The new Intel stuff is tolerable for desktop use, same as it's always been.
21:16:00 <Bitweasil> Hardware accelerated cursors and other modern features like that.
21:17:00 <qookie> my intel hd graphics 4000 is still working fine for me :^)
21:17:00 <Bitweasil> But for that money, if you're not opposed to it, you could get a M1 laptop of some variety that would be a lot quicker.
21:17:00 <Bitweasil> My... hrm.
21:17:00 <gog> Bitweasil: gaymes
21:17:00 <Arsen> qookie becomes an irc regular part 1
21:17:00 <Bitweasil> I've got... is 965 the old chipset stuff that's used on the Atoms?
21:18:00 <c2a1> How can HD 4000 do chrome even
21:18:00 <c2a1> Yes
21:19:00 <qookie> it working fine
21:19:00 <Bitweasil> At some point, you just treat it as a framebuffer-to-monitor driver. :p
21:19:00 <Bitweasil> What generation is the HD 4000 in?
21:19:00 <qookie> 7th iirc
21:19:00 <qookie> ivy bridge
21:19:00 <Bitweasil> ... what graphics *does* this laptop have? *pokes*
21:19:00 <Bitweasil> Oh, new stuff.
21:20:00 <c2a1> Ivy bridge is like 2011 if I'm not wrong
21:20:00 <Bitweasil> I thought it was a bit newer.
21:20:00 <Arsen> 2013?
21:20:00 <Bitweasil> Maybe it's the same era as this netbook.
21:20:00 <Arsen> >From April 29, 2012 to June 5, 2015
21:20:00 <Bitweasil> I've got an Atom D525.
21:20:00 <c2a1> Bitweasil, what kind of computer are you using
21:20:00 <Bitweasil> Ok, that sounds right for Ivy. IIRC that was the first gen with unrestricted guest support.
21:20:00 <c2a1> Oh
21:20:00 <Bitweasil> er, which one?
21:20:00 <Bitweasil> Right now, a RasPi4.
21:21:00 <c2a1> I used an atom n270 and it moved at a snails pace.
21:21:00 <Arsen> the ivy bridge logo is p cool
21:21:00 <Arsen> https://upload.wikimedia.org/wikipedia/commons/0/06/Ivy_Bridge_Codename_Logo.jpg
21:21:00 <c2a1> A raspi 4 is probably faster
21:22:00 <Bitweasil> This netbook is an old ASUS netbook, D525, "Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller."
21:22:00 <Bitweasil> Oh, certainly.
21:22:00 <c2a1> It can do regular opengl even so I could probably put that to the test if I werent likely going homeless soon
21:24:00 <Bitweasil> The Pi4 however is not portable.
21:24:00 <Bitweasil> In a useful sense of the word.
21:25:00 <clever> Bitweasil: pi400?
21:25:00 <Bitweasil> Doesn't have a monitor.
21:25:00 <Bitweasil> I have a perfectly good little ARM laptop too.
21:25:00 <Bitweasil> But some of what I have to do when I'm mobile is better served by x86 and a physical ethernet port.
21:26:00 <c2a1> Pinebook?
21:26:00 <Bitweasil> Pro, yeah.
21:27:00 <c2a1> Oh that's cool.
21:27:00 <Bitweasil> It's my daily driver in the house, but I don't have good x86/WINE translation going on it, and some of the network admin tools I use are x86 (Winbox).
21:27:00 <clever> Bitweasil: https://www.youtube.com/watch?v=t-ZQ9LRdXSk ?
21:27:00 <bslsk05> 'Finally! A Raspberry Pi Linux Tablet that works!' by Jeff Geerling (00:26:30)
21:27:00 <Bitweasil> So I keep the old netbook around for that, and it's actually... if not, fast, tolerable with Linux and Win10.
21:27:00 <Bitweasil> lulz, you should know better than to link me to a video.
21:27:00 <Bitweasil> This box has neither sound nor working video at the moment.
21:27:00 <c2a1> Do you have anything more powerful?
21:28:00 <Bitweasil> Yeah, but I feel dirty using them.
21:28:00 <c2a1> I had a MacBook air but I lost it in transit.
21:28:00 <Bitweasil> I've got an ODroid N2+ desktop... ;)
21:28:00 <Bitweasil> I actually have some more modern x86 stuff.
21:28:00 <Bitweasil> I've got a... oh, what's in it...
21:28:00 <c2a1> Its GPU was giving me errors though. Overheated memory probably.
21:28:00 <Bitweasil> Skull Canyon NUC?
21:29:00 <c2a1> Who knew steam games could kill a laptop
21:29:00 <Bitweasil> i7-6770HQ?
21:29:00 <c2a1> Apple used to have notoriously bad laptop build quality and now they're hailed for it
21:29:00 <Bitweasil> And I've got a tolerable recent desktop in the house, maybe 8000 something or other Intel? I should replace it.
21:29:00 <Bitweasil> 8700K, maybe?
21:29:00 <Bitweasil> And an old 980 GPU.
21:30:00 <Bitweasil> But I feel dirty using modern computers of the fast x86 variety.
21:30:00 <Bitweasil> Even though nothing actually works on ARM. :(
21:30:00 <c2a1> Heh most open source linux packages do
21:30:00 <Bitweasil> Node stuff still really struggles with AArch64 builds.
21:31:00 <j`ey> as in, node.js?
21:31:00 <Bitweasil> So I don't have Signal, Element is iffy (no native stuff gets built so search doesn't work), Spotify is a problem (ncspot is OK but has some weird issues with garbling audio badly), etc.
21:31:00 <Bitweasil> Yeah.
21:31:00 <Bitweasil> :/
21:31:00 <Bitweasil> "The environment in which everything is written anymore."
21:43:00 <Bitweasil> I also have a couple x86 servers that are fairly powerful.
21:43:00 <Bitweasil> But could replace at least one of them with a little ARM box, if I could bolt enough storage in.
21:43:00 <Bitweasil> (An 8 core ARM box with 32GB or 64GB RAM, for not "custom server" prices, would solve a lot of my problems)
21:44:00 <Bitweasil> A bunch of X2 cores or something.
21:44:00 <j`ey> (and not apple :P)
21:45:00 <c2a1> Are they cheaper than x86 servers usually
21:45:00 <Bitweasil> Right now, no.
21:45:00 <c2a1> I'd buy an arm based Xserve comeback
21:45:00 <Bitweasil> ... yeah, and not Apple. Unfortunately, "Win10 VMs" are something I make use of.
21:45:00 <Bitweasil> For DRM stripping ebooks and such.
21:46:00 <c2a1> Then power efficiency is the only selling point right now
21:46:00 <Bitweasil> I disagree.
21:46:00 <Bitweasil> Anandtech has done quite a few reviews, and in a lot of workloads, not only are the ARM servers more power efficient, they're absolutely faster.
21:46:00 <c2a1> What are the others?
21:46:00 <Bitweasil> It depends a bit on your workloads, but for stuff that's not single thread performance bound, the high core count ARM boxes really put in a good showing.
21:47:00 <c2a1> Heh
21:47:00 <c2a1> Amd could do better
21:47:00 <Bitweasil> Their recent high core count chips are pretty solid too.
21:47:00 <Bitweasil> I'm just over x86... unless someone wants to pay me a lot.
21:47:00 <Bitweasil> ARM is ugly too.
21:47:00 <Bitweasil> I honestly think I'm burning out of low level tech and computers entirely.
21:49:00 <c2a1> How is an isa ugly lol
21:49:00 <c2a1> They're all ugly trust me
21:49:00 <Bitweasil> I'm in ARMv7 at the moment.
21:49:00 <Bitweasil> It's the worst of all the ARM worlds from what I hear. Lots of banked registers and stuff hacked in.
21:49:00 <Bitweasil> "Bolt it on and ship it!" style stuff.
21:49:00 <c2a1> x86 for one is actually the ugliest
21:50:00 <c2a1> Forgot what channel I was in
21:50:00 <Bitweasil> Trade you for the horrors of the ARMv7 MMU, dealing with banked registers for monitor/hypervisor/os/user, both secure and non, if implemented. That's a mess. :(
21:51:00 <Bitweasil> x86 is ugly as well.
21:51:00 <Bitweasil> But in some ways, ARMv7 has "more crap bolted on."
21:51:00 <Bitweasil> Supposedly ARMv8 cleans up a lot of it, but I've not started reading that reference doc yet.
21:51:00 <Bitweasil> And I'm at the other end, I'm writing emulators, so I have to implement the stuff in software.
21:52:00 <Bitweasil> You can ignore a lot of the ugly if you're just writing an OS for it.
21:55:00 <qookie> hmmmmm what is udev doing https://owo.whats-th.is/5CEFgBH.png
21:57:00 <c2a1> Isnt x86 8080 -> 8086 -> i386 -> x86_64
21:58:00 <c2a1> Or are 8086 and 8080 not compatible
21:58:00 <c2a1> I thought the lower and higher halves of each 16 bit register were for pseudocompatibility
21:58:00 <qookie> iirc they're source compatible but not binary compatible
21:59:00 <Bitweasil> The 8080 was an 8 bit chip, IIRC. The 8086/8088 are 16-bit.
22:04:00 <c2a1> https://pastraiser.com/cpu/i8080/i8080_opcodes.html
22:04:00 <bslsk05> pastraiser.com: Intel 8080 OPCODES
22:04:00 <c2a1> Correct. Not compatible
22:04:00 <c2a1> But similar
22:13:00 <chibill[m]> <Bitweasil> "What's the issue with discrete..." <- I have a dislike of their handling of drivers for Windows. My sandybridge had issues on Win10. Xd
22:14:00 <Bitweasil> Linux driver is just fine...
22:14:00 <Bitweasil> :p
22:37:00 <qookie> https://owo.whats-th.is/2MMoufn.png holy crap it finally works
22:37:00 <qookie> it was a really dumb mistake as well
22:38:00 <qookie> i forgot to enable memory decode in the bridge's pci command reg
22:38:00 <clever> qookie: ah, that sounds important
22:38:00 <clever> qookie: also of note, the bcm2711 has 2 xhci controllers
22:39:00 <clever> if you put otg_mode=1 into config.txt, a second xhci will appear in your device-tree
22:39:00 <clever> that 2nd xhci controller, is routed to the usb-c port, but is usb2.0 only
22:39:00 <qookie> isn't the usb-c port handled by a designware controller?
22:39:00 <qookie> or is that one xhci compatible as well
22:39:00 <clever> both the dwc2 and the xhci controller share a single usb phy
22:40:00 <clever> otg_mode= selects which usb controller is enabled
22:40:00 <qookie> ah
22:40:00 <clever> with the default (otg_mode=0 i believe), you can enable the dwc (it must be enabled with an overlay), and then do device or host stuff
22:41:00 <clever> the closed firmware does undocumented things to enable and route things
22:41:00 <qookie> huh
22:41:00 <clever> but with otg_mode=1, the xhci controller is enabled instead, and can do host-only usb2 stuff
22:41:00 <qookie> also some more good news: legacy pci irqs work fine without any special setup (broadcom didn't break them :^)
22:42:00 <qookie> bad news is that my xhci driver is unhappy and doesn't want to acknowledge the irqs
22:43:00 <clever> if you flip on otg_mode=1, youll have a second xhci to play with, and find more edge cases!
22:43:00 <qookie> just what i needed
22:44:00 <clever> i heard that linux had an edge case, where it didnt like an xhci controller with no usb3 ports
22:59:00 <Bitweasil> Wouldn't surprise me, that's an odd one...
23:04:00 <clever> Bitweasil: and this is my latest investigatings into hw scaling on the rpi: https://cdn.discordapp.com/attachments/872036106122698752/908491617239969822/20211111_190113.jpg
23:04:00 <clever> the input bitmap is a 102x102 pixel image, with a grid drawn on it
23:05:00 <clever> the output is configured to sweep from 5x5 to 200x200, so it both downscals and upscales
23:06:00 <Bitweasil> Huh, fun!
23:09:00 <clever> Bitweasil: https://youtu.be/_3MWwF_2Ln0 is a full animation
23:09:00 <bslsk05> 'HVS scaling animation test' by michael bishop (00:00:16)
23:10:00 <clever> for 102x102 and below, it uses a down-scaling mode that appears to work perfectly
23:10:00 <clever> but above that size, its using an upscaling mode that i havent fully implemented
23:23:00 <clever> Bitweasil: https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_hvs.c#L215-L275
23:23:00 <bslsk05> github.com: linux/vc4_hvs.c at rpi-5.10.y · raspberrypi/linux · GitHub
23:23:00 <clever> so the next course of action for tomorrow, is to port this over, and try and understand what the heck its doing
23:40:00 <c2a1> Is the VC GPU open source as far as drivers go
23:41:00 <c2a1> When the pi 1 came put that seemed like a big issue that they werent