Back in the late 90s to early 2000s, SiS graphics chips were fairly common and found in many low-end devices. Today, the chips are still capable enough for simple graphics needs, but the graphics cards were on PCI and AGP buses. They are not usable in modern computers.
However, there exist USB-based graphics cards with a SiS 315 graphics chip. Those are around on Ebay et al [1] and easily usable with current computers. I already do have a driver for the old PCI-based SiS drivers and have long been struggling to find something useful to do with it. Converting it to serve USB devices would finally make it useful.
The goal for Hackweek 20 is to dedust my SiS driver and make it work with the 315 chip. That might take a bit or not; I'm not sure yet. Afterwards, the PCI I/O needs to be replaced with corresponding USB operations.
There are quite a few resources. My PCI driver is at [2]. For the USB devices, there exists an old userspace driver at [3] and a kernel stub at [4]. A general description of the device can be found in the Wayback Machine. [5]
If successful, the driver is supposed to be included in the upstream kernel.
[1] https://www.amazon.com/Tritton-TRI-UV100-SEE2-SVGA-Adapter/dp/B0003NFY1E
[2] https://gitlab.freedesktop.org/tzimmermann/linux/tree/sisvga
[3] https://gitlab.freedesktop.org/xorg/driver/xf86-video-sisusb
[5] https://web.archive.org/web/20100610174735/http://www.winischhofer.eu/linuxsisusbvga.shtml
This project is part of:
Hack Week 20
Activity
Comments
-
over 4 years ago by tdz | Reply
Day 1: Today I returned to my old driver for SiS PCI devices, which used to work 3yrs ago. Admittedly, the driver has bit-rotted quite a bit. I since updated it and added atomic modesetting. But I never really tested these changes. I can get the modes from the monitor via EDID functionality and the driver now detects the VRAM size correctly. My monitor reports a signal error, which indicates a bug when programming display resolution or timing. Fixing the driver is what I currently do. I'll also have to update it for the 315 chip. My hope is that I can then replace the PCI-bus functionality with USB and have a semi-working USB driver later this week.
-
over 4 years ago by tdz | Reply
Day 2: I'm still working on getting the old PCI-based SiS driver to work correctly within the current kernel. I managed to get the display mode set and improved color-format settings. The display still looks wrong, but it's getting better. I give it one more day. No matter what the state is tomorrow, I'll push for USB support on Thursday.
-
-
over 4 years ago by tdz | Reply
Day 4: I began to turn the PCI driver into a USB driver. Each PCI I/O operation has to be converted to a USB bulk message. The rsp code is already in the old kernel stub driver somewhere. The PCI device is a VGA card and therefore POSTed by the BIOS. For the USB device, I expect that there might be an additional POST process necessary. The old userspace driver should have the rsp code somewhere. No way I'll be able to finish all of this by the end of the week.
-
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
Backporting patches using LLM by jankara
Description
Backporting Linux kernel fixes (either for CVE issues or as part of general git-fixes workflow) is boring and mostly mechanical work (dealing with changes in context, renamed variables, new helper functions etc.). The idea of this project is to explore usage of LLM for backporting Linux kernel commits to SUSE kernels using LLM.
Goals
- Create safe environment allowing LLM to run and backport patches without exposing the whole filesystem to it (for privacy and security reasons).
- Write prompt that will guide LLM through the backporting process. Fine tune it based on experimental results.
- Explore success rate of LLMs when backporting various patches.
Resources
- Docker
- Gemini CLI
Repository
Current version of the container with some instructions for use are at: https://gitlab.suse.de/jankara/gemini-cli-backporter
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !) Compute power is barely enough for Curve25519, Flash memory leaves room for only 3 keys.
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it. Besides, NXP's support for open source toolchains for its devboards is extremely limited.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. Best OSS support seems to be for STM32-based products.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
STM32 Nucleo, blackmagic probe, tropicsquare tropic01, arm-none cross toolchain