Project Description
The Steam Deck is a portable gaming handheld built around platform technology similar to the one found in AMD mobile laptops. Vendor Valve ships a custom Linux distribution with downstream patches on this device, but booting into other distributions is possible. Connecting the Steam Deck to a dock can turn it into a compact workstation.
While a lot of patches have been upstreamed or rewritten for upstream, some upstream-only issues persist. Archlinux users work around this by just using Valve's downstream versions which is not the route I would like to take.
I already had a chance to explore these issues last year and got a lot of help from cool developers such as tiwai. But I did not get as far as I would have liked. I want to revisit these issues and learn more about kernel work. As a kernel newbie I am looking forward to learning more.
I appreciate help, pointers, tips and tricks from experienced maintainers. Kernel newbies such as myself are also very welcome to join, too. Some open issues already contain commands that you can use to collect information and help you learn, so make sure to take a look at the existing Bugzilla reports.
Goal for this Hackweek
- retest known issues with the latest Tumbleweed snapshot
- figure out how to collect useful information and research around drivers
- revive these open issues and hopefully come closer to finding a solution
- learn a bunch about the kernel, drivers and debugging (probably mostly ALSA ASoC, DRM, x86_64 ACPI)
- try patching the Tumbleweed kernel and see what happens
- write a small blog post about how it went including some photos
Resources
- Currently open issues: https://bugzilla.opensuse.org/buglist.cgi?quicksearch=steam+deck
- Valve hosts their source code as src.tar.gz containing bare git repos: https://steamdeck-packages.steamos.cloud/archlinux-mirror/sources/jupiter-main/
This project is part of:
Hack Week 22
Activity
Comments
Similar Projects
pudc - A PID 1 process that barks to the internet by mssola
Description
As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:
- The backend is written in a mixture of C and RISC-V assembly.
- The backend is actually PID1 (for real, not within a container).
- We poll and parse incoming HTTP requests ourselves.
- The frontend is a mere HTML page with htmx.
The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.
I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.
Goals
- Have a better understanding of different Linux features from user space down to the kernel internals.
- Most importantly: have fun.
Resources
Add Qualcomm Snapdragon 765G (SM7250) basic device tree to mainline linux kernel by pvorel
Qualcomm Snapdragon 765G (SM7250) (smartphone SoC) has no support in the linux kernel, nor in u-boot. Try to add basic device tree support. The hardest part will be to create boot.img which will be accepted by phone.
UART is available for smartphone :).
Improve UML page fault handler by ptesarik
Description
Improve UML handling of segmentation faults in kernel mode. Although such page faults are generally caused by a kernel bug, it is annoying if they cause an infinite loop, or panic the kernel. More importantly, a robust implementation allows to write KUnit tests for various guard pages, preventing potential kernel self-protection regressions.
Goals
Convert the UML page fault handler to use oops_* helpers, go through a few review rounds and finally get my patch series merged in 6.14.
Resources
Wrong initial attempt: https://lore.kernel.org/lkml/20231215121431.680-1-petrtesarik@huaweicloud.com/T/
bpftrace contribution by mkoutny
Description
bpftrace is a great tool, no need to sing odes to it here. It can access any kernel data and process them in real time. It provides helpers for some common Linux kernel structures but not all.
Goals
- set up bpftrace toolchain
- learn about bpftrace implementation and internals
- implement support for
percpu_counters - look into some of the first issues
- send a refined PR (on Thu)
Resources
dynticks-testing: analyse perf / trace-cmd output and aggregate data by m.crivellari
Description
dynticks-testing is a project started years ago by Frederic Weisbecker. One of the feature is to check the actual configuration (isolcpus, irqaffinity etc etc) and give feedback on it.
An important goal of this tool is to parse the output of trace-cmd / perf and provide more readable data, showing the duration of every events grouped by PID (showing also the CPU number, if the tasks has been migrated etc).
An example of data captured on my laptop (incomplete!!):
-0 [005] dN.2. 20310.270699: sched_wakeup: WaylandProxy:46380 [120] CPU:005
-0 [005] d..2. 20310.270702: sched_switch: swapper/5:0 [120] R ==> WaylandProxy:46380 [120]
...
WaylandProxy-46380 [004] d..2. 20310.295397: sched_switch: WaylandProxy:46380 [120] S ==> swapper/4:0 [120]
-0 [006] d..2. 20310.295397: sched_switch: swapper/6:0 [120] R ==> firefox:46373 [120]
firefox-46373 [006] d..2. 20310.295408: sched_switch: firefox:46373 [120] S ==> swapper/6:0 [120]
-0 [004] dN.2. 20310.295466: sched_wakeup: WaylandProxy:46380 [120] CPU:004
Output of noise_parse.py:
Task: WaylandProxy Pid: 46380 cpus: {4, 5} (Migrated!!!)
Wakeup Latency Nr: 24 Duration: 89
Sched switch: kworker/12:2 Nr: 1 Duration: 6
My first contribution is around Nov. 2024!
Goals
- add more features (eg cpuset)
- test / bugfix
Resources
- Frederic's public repository: https://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git/
- https://docs.kernel.org/timers/no_hz.html#testing
Progresses
isolcpus and cpusets implemented and merged in master: dynticks-testing.git commit