• waigl@lemmy.world
      90·
      5 hours ago

      This is x86 assembler. (Actually, looking at the register names, it’s probably x86_64. On old school x86, they were named something like al, ah (8 bit), ax (16 bit), or eax (32 bit).) Back in the old days, when you pressed a key on the keyboard, the keyboard controller would generate a hardware interrupt, which, unless masked, would immediately make the CPU jump to a registered interrupt handler, interrupting whatever else it was doing at the point. That interrupt handler would then usually save all registers on the stack, communicate with the keyboard controller to figure out what exactly happened, react to that, restore the old registers again and then jump back to where the CPU was before.

      In modern times, USB keyboards are periodically actively polled instead.

      • WhyJiffie@sh.itjust.worksEnglish
        11·
        3 hours ago

        does that mean though that if I connect a PS/2 keyboard or mouse to my relatively modern computer (a “gamer” motherboard made ~6 years ago) 's PS/2 port, that it’ll still trigger such an interrupt?

        • atomicbocks@sh.itjust.worksEnglish
          7·
          1 hour ago

          The other commenter is on the right track but the chip controls both USB and PS/2 as well as others;

          In the 90s and 2000s, for x86 machines, slower I/O was handled by a chip called the Southbridge which worked in conjunction with a chip called the Northbridge that handled faster I/O like IDE and PCI. Later these were integrated into a single chip and, as of recent processor generations, into the processor itself.

          AFAIK ghosting and key rollover are issues when using PS/2 but it can offer some milliseconds off latency when used in high cpu games.

          • DeRp_DaWg@lemmy.world
            1·
            30 seconds ago

            AFAIK ghosting and key rollover are issues when using PS/2

            I think it’s more of an issue for USB keyboards than PS/2 keyboards.

        • Colloidal@programming.devEnglish
          6·
          3 hours ago

          I think there’s a USB device inside the mobo to handle dumb peripherals. So it would still trigger an interrupt, but it wouldn’t make it to the CPU. The USB keyboard controller would handle it and cache the strokes locally until polled by the CPU.

          • grue@lemmy.world
            4·
            2 hours ago

            I would expect that any motherboard that went to the trouble of including a PS/2 port would handle it with a real hardware interrupt, because the whole point of still having those things is to avoid the latency overhead of USB.

      • lunachocken@lemm.ee
        7·
        3 hours ago

        I had to write a mini os and it handled keyboard interrupts. Certainly made it make a lot more since after writing it for my uni course

    • Something Burger 🍔@jlai.lu
      24·
      5 hours ago

      The small bird is a CPU executing its instructions. The big bird is a keyboard sending an interrupt for the CPU to process immediately.

  • istdaslol@feddit.org
    37·
    6 hours ago

    And their interrupt routine has an error that leads to changed memory and you don’t know why your Programm calculates „2+6=E“ and that only sometimes on every other run.

    • perishthethought@lemm.eeEnglish
      3·
      4 hours ago

      !!! I just learned about this recently because my PC has an Nvidia GPU and it sometimes wakes up from sleeping to a blank screen with just the mouse cursor showing.

      I try that REISUB first but if that doesn’t do anything, I have to go to Ctrl-Alt-F3 and do “sudo reboot”.

      Linux is fun except for when it’s not.

      • hddsx@lemmy.ca
        4·
        4 hours ago

        I’m confused. Why would you REISUB/O if you can use the reboot command?

        REISUB is a last resort before hitting the physical power button

          • lime!@feddit.nuEnglish
            5·
            1 hour ago

            reisub is not “safe”. it is the “safest” way when your system has reached an otherwise broken state, but you’re still interrupting things that may be saving state or changing configurations. if your system is working behind the scenes you may very well break it more.

          • hddsx@lemmy.ca
            2·
            2 hours ago

            You should really use the reboot command first because you don’t have to control the order and timing. REISU(B/O) requires pauses between letters for the specific action to run. It also requires those letters to be in that particular order - you can’t sync the file system if you put it into read only. If REISUB is sometimes not working but you can go elsewhere and reboot, you’re likely not doing it right and you should err on the side of caution and use the reboot command

      • grue@lemmy.world
        2·
        2 hours ago

        I don’t know about AM5, but I’m running a 5700X3D on a motherboard that still has a PS/2 port. (Not that I’m using it, but it’s there.) You can still have a pretty modern system with PS/2 if you really want it.

      • dual_sport_dork 🐧🗡️@lemmy.worldEnglish
        7·
        4 hours ago

        Never mind recent motherboards, I’m still salty about the era of boards from 2004-2010 or so which had USB ports but the BIOS would refuse to accept inputs from them until after POST so you’d have to dredge up a separate PS/2 keyboard and jack it in to be able to configure the damn thing or use the boot menu.

        And I had at least one board from that time period which has this same flaw, but with the added layer of joy and excitement that they’ve removed the PS/2 port block in order to appear “modern.” It’s still there, of course, but only as a pin header that you need to access from inside the case and plug a breakout board into. If you lose that board the gods themselves couldn’t even help you. I used to keep it stuck with painters tape to the inside of the case side panel.

        • sylver_dragon@lemmy.worldEnglish
          2·
          1 hour ago

          Never mind recent motherboards, I’m still salty about the era of boards from 2004-2010 or so which had USB ports but the BIOS would refuse to accept inputs from them until after POST so you’d have to dredge up a separate PS/2 keyboard and jack it in to be able to configure the damn thing or use the boot menu.

          Had one of these in a server rack. Which was all kinds of fun because the rack KVM was USB. We ultimately just left the PS/2 keyboard plugged in and sitting on top of the server in the rack. Given the shitshow which was cable management in those racks (we shared them with several departments), that keyboard was hardly the worst sin.

        • talEnglish
          4·
          3 hours ago

          Ehhh.

          So, the initial, and real reason that NKRO was introduced was to deal with inexpensive keyboards that used grid encoders. This requires that each key be assigned a place on a grid, with each row and column having a wire associated with it. When you push a key, it sends the associated pair of wires high voltage. The keyboard encoder chip has those wires running to its pins.

          Such a scheme can permit detecting any one key going down, which will always set two wires to high voltage. It can permit detecting any two keys going down, since that will always set at least one more line to high voltage, which will uniquely identify the key. But beyond that, additional keys may not be possible to uniquely identify (and, in fact, pushing one may send only lines that are already high to high, which is totally invisible to the encoder), and so it may ignore additional keys.

          This prevents a grid-based encoder from doing NKRO.

          If you want to do NKRO, you have to have a unique line coming from every keyswitch, which costs money.

          There is a second issue with NKRO.

          You can have a keyboard that can have NKRO to the encoder, rather than a grid. And can have a USB interface to talk to the computer.

          But last I looked, USB has a protocol limitation that cannot support NKRO, and this was a major reason that you could still get some dual-interface keyboards with PS/2 support and USB recently.

          PS/2 is edge-triggered by a key. A key goes down, the computer gets a message. A key goes up, the computer gets a message. All that message says is “this key went down” or “this key went up”. The computer maintains a list of keys and its idea of the up or down state of them.

          This is also why PS/2 keyboards can sometimes have keys that appear to be “stuck” that get unstuck when you tap them — if the computer misses the “up” message for some reason, then it only gets notified about it next time the key changes state and the computer gets a message about it.

          USB doesn’t work like that. When a USB keyboard sends an event, it contains a dump of the keyboard state. Every keypress, new dump. However, there’s a restriction on the size of the message. It can only contain…I think it’s seven keys that are down, plus modifier keys.

          kagis

          Six keys.

          In practice, six is probably enough for pretty much anyone. The real problem was grid encoders, as a video game player might legitimately hit three or four keys at once. But…it still isn’t, strictly-speaking, NKRO unless it can do all.

          It looks like there are basically two approaches that keyboards have used to try to provide a similar effect. One is to just invent a proprietary protocol, and rely on that and a driver rather than the standard USB keyboard behavior.

          The other is to tell the computer that the keyboard is a whole array of keyboards. Since most OS environments can use multiple keyboards and just use their input, such a keyboard can pretend to have multiple keyboards pressing buttons.