The Raspberry Pi 400 thread!

[karrika]

So the encoder has nothing to do with power on/off.

Pressing two keys for 2 sec is easily catched in the kernel.

Power on by pressing F10 does not really apply power as the unit is powered from the USB C port. So you can just put chips in suspend state and wait for F10.

[ejolson]

That would be one of these on the Pi 400 ...

Thanks. OTP according to that which isn't surprising, so little scope for altering functionality there, unless replacing the chip.

Ah, missed that bit, shame as I'm sure some people would hack away and see what weird, interesting stuff they could make the keyboard do

In a way I'm glad the keyboard controller is only one-time programmable, as I suspect a key logger would have been one of the first projects.

Does the Pi 400 power on immediately after recieving power, or does one need to push the power button as well after plugging it in the first time?

[cleverca22]

So the encoder has nothing to do with power on/off.

Pressing two keys for 2 sec is easily catched in the kernel.

Power on by pressing F10 does not really apply power as the unit is powered from the USB C port. So you can just put chips in suspend state and wait for F10.

my theory, is that there is a mosfet somewhere, that can cut the main 5v rail off when you shutdown, and then the SoC is 100% dead

but the uC handling the keyboard matrix remains active (on the usb-c side), and can turn that mosfet back on when you hit the magic key

the keyboard uC might even stop its scanning, just activate one row permanently, and then use gpio edge interrupts on the right column, so it can only wake to a single key

but ive not checked its datasheet in detail, to see if its capable of that

still waiting for my pi400 to arrive, and then i can begin to analyze and confirm/deny my theories

[W. H. Heydt]

4- Bonus question:
You know what would be awesome on the Pi 400?
To have a a microUSB OTG cable (or USB type C cable), to use the Pi 400 as just a keyboard.

You didn't notice that Pi keyboards are available without the SOC etc? Much lower cost, full keyboard functionality of the Pi400 (except power control, but that wouldn't work on a target PC).

This was my first reaction too but it has some merit, kind of remote desktop/KVM, imagine your Pi 400 with monitor and then another Pi or PC with screen next to it but no keyboard. Happens to me when having more Pi-s on the desk , e.g. two displays, two Pi-s, just one keyboard. In fact I was just thinking about ordering second raspberry keyboard when Pi400 came. Obviously I ordered Pi400 but now I will have three Pis with two keyboards, same problem.

Won't quite work with a Pi400...but my general solution is two (hopefully, 3 some time late next Spring) KVM switches. I have enough ports to handle 11 devices, assuming the right sorts of connections are available on them.

[karrika]

So the encoder has nothing to do with power on/off.

Pressing two keys for 2 sec is easily catched in the kernel.

Power on by pressing F10 does not really apply power as the unit is powered from the USB C port. So you can just put chips in suspend state and wait for F10.

my theory, is that there is a mosfet somewhere, that can cut the main 5v rail off when you shutdown, and then the SoC is 100% dead

but the uC handling the keyboard matrix remains active (on the usb-c side), and can turn that mosfet back on when you hit the magic key

the keyboard uC might even stop its scanning, just activate one row permanently, and then use gpio edge interrupts on the right column, so it can only wake to a single key

but ive not checked its datasheet in detail, to see if its capable of that

still waiting for my pi400 to arrive, and then i can begin to analyze and confirm/deny my theories

There seems to be more naughty kids on the block that want to take their Pi 400 apart to see what makes it tick.

I did read the datasheet of the controller. It can go to low power sleep by executing HALT.

It can wake from sleep by taking an IO-line from high to low.

But this also means that all the keyboard scan lines must be hi or low. They cannot be floating. As wakeup reacts to a key press going from high to low that scan line must be powered.

I really don't see why they would have added a powerful MOSFET to the 5V rail. Software is cheaper.

On a portable unit a MOSFET makes perfect sense. But the Pi 400 does not run on batteries.

[ejolson]

You didn't notice that Pi keyboards are available without the SOC etc? Much lower cost, full keyboard functionality of the Pi400 (except power control, but that wouldn't work on a target PC).

This was my first reaction too but it has some merit, kind of remote desktop/KVM, imagine your Pi 400 with monitor and then another Pi or PC with screen next to it but no keyboard. Happens to me when having more Pi-s on the desk , e.g. two displays, two Pi-s, just one keyboard. In fact I was just thinking about ordering second raspberry keyboard when Pi400 came. Obviously I ordered Pi400 but now I will have three Pis with two keyboards, same problem.

Won't quite work with a Pi400...but my general solution is two (hopefully, 3 some time late next Spring) KVM switches. I have enough ports to handle 11 devices, assuming the right sorts of connections are available on them.

With a keyboard built into the computer there is no need for a KVM switch. At the same time, one should still be able to plug another keyboard into the Pi 400 and use that in place of or in addition to the built-in one.

Given how well RealVNC works and even the xorgxrdp remote desktop, I see little reason for switching the same keyboard between multiple computers. Simply attach one keyboard and two monitors to the computer which needs ultra-low latency for gaming and conferencing; then use the others through the network.

It's an amazing to think a single Pi 400 could be the point from which to control all other networked computers.

[HermannSW]

Presuming the same USB Via Hub Chip as 4B total for all 4 ports (keyboard use one) is 1200mA.

In this posting
viewtopic.php?f=63&t=290131&p=1755625#p1754996
W. H. Heydt made me aware that a USB 3.0 port needs to be capable of delivering 0.9A.
I just looked up for USB 2.0, and there it is 0.5A.
So Pi4B as well as Pi400 with only 1200mA are underpowered for 4 USB ports (2*0.5A+2*0.9A=2.8A would be needed according spec):
https://en.wikipedia.org/wiki/USB

USB.current.png

USB.current.png (13.34 KiB) Viewed 1025 times

There is a <10$ 4port USB 3.0 hub that can be powered with 5V/2A.
If using only two of the 4 ports, they are correctly powered.
If connecting two of those hubs to both Pi400 USB 3.0 ports, and using only 2 ports per hub, you get 4 correctly powerd USB 3.0 ports (4*0.9A < 2*2A) for the Pi400:

USB_3.0.active.png

USB_3.0.active.png (92.36 KiB) Viewed 1025 times

[W. H. Heydt]

So Pi4B as well as Pi400 with only 1200mA are underpowered for 4 USB ports (2*0.5A+2*0.9A=2.8A would be needed according spec):
https://en.wikipedia.org/wiki/USB
USB.current.png

Yes. That has always been the case with Pis. The original Model B had 140mA polyfuses, one for each (of two) USB 2 ports. Those were first replaced by zero ohm resistors (a simple change in component with no PCB change) and later eliminated altogether.

Who knows...perhaps the innovative change for the Pi5B will be to provide standard specified power for the USB ports... (That would probably mean a board specification of a 5A PSU.)

[hippy]

So the encoder has nothing to do with power on/off.

Pressing two keys for 2 sec is easily catched in the kernel.

Power on by pressing F10 does not really apply power as the unit is powered from the USB C port. So you can just put chips in suspend state and wait for F10.

Sure, the kernel can catch the shutdown key combination; but how does it catch the power-up key press ? It can only do that if the SoC is powered up and running, along with a USB stack, which means soft power-off is far short of powered off. I can't see that as the chosen model but perhaps it is.

It could be that the kernel catches shutdown and there's some additional hardware monitoring the single key which powers it back on.

The keyboard encoder is programmable and low power so that's where I'd put the on-off control.

But we won't know until someone tells us or reverse engineers the circuitry and figures out where control signals go.

[W. H. Heydt]

This was my first reaction too but it has some merit, kind of remote desktop/KVM, imagine your Pi 400 with monitor and then another Pi or PC with screen next to it but no keyboard. Happens to me when having more Pi-s on the desk , e.g. two displays, two Pi-s, just one keyboard. In fact I was just thinking about ordering second raspberry keyboard when Pi400 came. Obviously I ordered Pi400 but now I will have three Pis with two keyboards, same problem.

Won't quite work with a Pi400...but my general solution is two (hopefully, 3 some time late next Spring) KVM switches. I have enough ports to handle 11 devices, assuming the right sorts of connections are available on them.

With a keyboard built into the computer there is no need for a KVM switch. At the same time, one should still be able to plug another keyboard into the Pi 400 and use that in place of or in addition to the built-in one.

Given how well RealVNC works and even the xorgxrdp remote desktop, I see little reason for switching the same keyboard between multiple computers. Simply attach one keyboard and two monitors to the computer which needs ultra-low latency for gaming and conferencing; then use the others through the network.

It's an amazing to think a single Pi 400 could be the point from which to control all other networked computers.

I did note that putting a Pi400 (and my first one is due to be delivered today) behind a KVM switch won't really work... Well, it would, but there's no real point to it as it still has its own keyboard.

I do make some use of VNC, however I do my best to have a direct link (through the KVM switches) between a Pi being booted and the monitor on my desk so that the Pi will get the geometry right. The reason being that not all of my Pis use the same monitor geometry all the time, so I don't want to "hard code" that in config.txt. Beyond that...not all the systems behind the KVM switches are Pis, so even NOT having the Pis on a KVM switch, the switch is still needed.

There are other Pis that are up from time to time that I *don't* run through the KVM. The usual reason is that they're brought up for software update/upgrades, may be running RPiOS Lite, and ssh is suitable to doing the work. A typical use for that is a Pi0 or Pi0W with a 3.5" display on the GPIO pins. I just plug in a USB to Ethernet adapter and power and away it goes.

[mob-i-l]

So the encoder has nothing to do with power on/off.

Pressing two keys for 2 sec is easily catched in the kernel.

Power on by pressing F10 does not really apply power as the unit is powered from the USB C port. So you can just put chips in suspend state and wait for F10.

Fn alone doesn't send a keypress - it has to be used with other keys, so the OS just would wait for Scroll Lock being held down for two seconds and then do sudo poweroff. In that case it would also power off if Scroll Lock was sent from other keyboards. It could also be the keyboard controller that detects Fn+F10 and powers off using a GPIO (hopefully one not connected to the GPIO port in order not to interfere with user projects). Powering on could be done by the keyboard controller lowering GPIO3 (pin 5) for a short while when it detects F10.

This would be similar to this project:
https://howchoo.com/g/mwnlytk3zmm/how-t ... spberry-pi

[drgeoff]

It should be easy to determine whether the keyboard encoder chip or the kernel is catching the "power off" key combination. If it doesn't work with an external USB keyboard, it isn't the kernel. I don't have a Pi400 to try it.

[cleverca22]

So the encoder has nothing to do with power on/off.

Pressing two keys for 2 sec is easily catched in the kernel.

Power on by pressing F10 does not really apply power as the unit is powered from the USB C port. So you can just put chips in suspend state and wait for F10.

Fn alone doesn't send a keypress - it has to be used with other keys, so the OS just would wait for Scroll Lock being held down for two seconds and then do sudo poweroff. In that case it would also power off if Scroll Lock was sent from other keyboards. It could also be the keyboard controller that detects Fn+F10 and powers off using a GPIO (hopefully one not connected to the GPIO port in order not to interfere with user projects). Powering on could be done by the keyboard controller lowering GPIO3 (pin 5) for a short while when it detects F10.

This would be similar to this project:
https://howchoo.com/g/mwnlytk3zmm/how-t ... spberry-pi

Code: Select all

[clever@amd-nixos:~/apps/rpi/linux/arch/arm/boot/dts]$ vi bcm2711-rpi-400.dts
// =============================================
// Board specific stuff here

/ {
        power_ctrl: power_ctrl {
                compatible = "gpio-poweroff";
                gpios = <&expgpio 5 0>;
                force;
        };  
};

the old gpio-poweroff overlay has been baked into the default dtb for the pi400
it says that if external gpio 5 (the i2c gpio expander) goes to a certain state, it should act like the power button has been pressed
that gets routed to systemd, which will do the configured action for the power button, as it would on any x86 machine

but, that doesnt explain how things get turned back on
and the rpi4 draws 110mA, even in its lowest power state, thats definitely power you could save if you just cut power to the SoC entirely
the old POWER_OFF_ON_HALT could still be used for that, then the keyboard uC only has to poke the GLOBAL_EN to kick the PMIC back into gear, and it will come back up

[karrika]

So the encoder has nothing to do with power on/off.

Pressing two keys for 2 sec is easily catched in the kernel.

Power on by pressing F10 does not really apply power as the unit is powered from the USB C port. So you can just put chips in suspend state and wait for F10.

Fn alone doesn't send a keypress - it has to be used with other keys, so the OS just would wait for Scroll Lock being held down for two seconds and then do sudo poweroff. In that case it would also power off if Scroll Lock was sent from other keyboards. It could also be the keyboard controller that detects Fn+F10 and powers off using a GPIO (hopefully one not connected to the GPIO port in order not to interfere with user projects). Powering on could be done by the keyboard controller lowering GPIO3 (pin 5) for a short while when it detects F10.

This would be similar to this project:
https://howchoo.com/g/mwnlytk3zmm/how-t ... spberry-pi

Wow. I am surprised to learn that Fn does not send keycodes like the other modifiers do (Left Shift, Right Shift, Alt and Ctrl). But it actually modifies the keycodes sent by the keyboard.

I wonder if someone who already has a Pi 400 could run

Code: Select all

sudo showkey -k

And press F10. It probably reports "keycode 68"
On my laptop Fn + F10 returns "keycode 190" which is also "microphone on/off"

[Heater]

What I want to know is...

Could one use the Pi 400 as a regular keyboard to a PC or whatever?

[drgeoff]

What I want to know is...

Could one use the Pi 400 as a regular keyboard to a PC or whatever?

Probably, if the USB-C power socket is the same as on a 4B in the sense that it can function as a USB device. But same issue as with a 4B of getting enough power into the socket while connected to a USB host device.

[cleverca22]

What I want to know is...

Could one use the Pi 400 as a regular keyboard to a PC or whatever?

Probably, if the USB-C power socket is the same as on a 4B in the sense that it can function as a USB device. But same issue as with a 4B of getting enough power into the socket while connected to a USB host device.

ive been doing a lot of usb gadget testing on my pi4, and while the power led is basically off permanently (stuck below the trigger level), it seems to run "fine"

but i'm not actually mounting the SD card (it runs from an initrd), so there is nothing i could corrupt, it looses all state at shutdown, by design

[W. H. Heydt]

I should probably note, for the benefit of those reading this thread who have come here relatively recently, that I am probably an outlier in use of Pis, and that in more than one way. So remarks about my own setup (multiple KVM switches, bunches of Pi, and all) should not be taken as a typical of how most Pi owners are set up.

[cleverca22]

I should probably note, for the benefit of those reading this thread who have come here relatively recently, that I am probably an outlier in use of Pis, and that in more than one way. So remarks about my own setup (multiple KVM switches, bunches of Pi, and all) should not be taken as a typical of how most Pi owners are set up.

you may also want to look into software like synergy

with that, you can trivially manage a dozen systems from a single keyboard/mouse, as long as each one has its own monitor

[ejolson]

What I want to know is...

Could one use the Pi 400 as a regular keyboard to a PC or whatever?

Probably, if the USB-C power socket is the same as on a 4B in the sense that it can function as a USB device. But same issue as with a 4B of getting enough power into the socket while connected to a USB host device.

I expect the latency would be irritating to first decode the USB keyboard inside the Pi 400 and then use the results to emulate another keyboard as a gadget through the USB C connector. On the other hand, it could make for the ultimate in programmable keyboards. Who's going to try it first?

[cleverca22]

What I want to know is...

Could one use the Pi 400 as a regular keyboard to a PC or whatever?

Probably, if the USB-C power socket is the same as on a 4B in the sense that it can function as a USB device. But same issue as with a 4B of getting enough power into the socket while connected to a USB host device.

I expect the latency would be irritating to first decode the USB keyboard inside the Pi 400 and then use the results to emulate another keyboard as a gadget through the USB C connector. On the other hand, it could make for the ultimate programmable keyboard. Who's going to try it first?

you could already try it with an rpi4, just read any keyboard (including usb) input via /dev/console or running the app on the console, and then HID gadget it back to another pc

[Heater]

PS/2 keyboard would do

[jdb]

What I want to know is...

Could one use the Pi 400 as a regular keyboard to a PC or whatever?

Probably, if the USB-C power socket is the same as on a 4B in the sense that it can function as a USB device. But same issue as with a 4B of getting enough power into the socket while connected to a USB host device.

I expect the latency would be irritating to first decode the USB keyboard inside the Pi 400 and then use the results to emulate another keyboard as a gadget through the USB C connector. On the other hand, it could make for the ultimate in programmable keyboards. Who's going to try it first?

Keyboards are polled over USB at no more than 1ms intervals (typically 8ms). This means - if you write your code sensibly - that the ~8ms poll time for the downstream keyboard is added to the <=1ms latency for the upstream "keyboard" so no more than 9ms lag. Barely perceptible.

Using a whole computer as a hosted keyboard seems like overkill, though...

[Heater]

Using a whole computer as a hosted keyboard seems like overkill, though...

Yes it would be.

The plan would be to have use of the Pi in the keyboard and whatever other machine it is is connected to, as a keyboard, at the same time. Hopefully saving keyboard clutter on the desk.

[jamesh]

Using a whole computer as a hosted keyboard seems like overkill, though...

Yes it would be.

The plan would be to have use of the Pi in the keyboard and whatever other machine it is is connected to, as a keyboard, at the same time. Hopefully saving keyboard clutter on the desk.

Just use Barrier.