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
-
almost 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.
-
almost 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.
-
-
almost 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
Hacking on sched_ext by flonnegren
Description
Sched_ext upstream has some interesting issues open for grabs:
Goals
Send patches to sched_ext upstream
Also set up perfetto to trace some of the example schedulers.
Resources
https://github.com/sched-ext/scx
Model checking the BPF verifier by shunghsiyu
Project Description
BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).
One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.
For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.
Goal for this Hackweek
Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.
Resources
- Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
- Has a section specifically on model checking
- Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
- Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
- [PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier
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/
Improve various phones kernel mainline support (Qualcomm, Exynos, MediaTek) by pvorel
Similar to previous hackweeks ( https://hackweek.opensuse.org/projects/improve-qualcomm-soc-msm8994-slash-msm8992-kernel-mainline-support, https://hackweek.opensuse.org/projects/test-mainline-kernel-on-an-older-qualcomm-soc-msm89xx-explore-mainline-kernel-qualcomm-mainlining) try to improve kernel mainline support of various phones.
Result
In the end I concentrated again to msm8994:
- 507aae9a3549c ("arm64: dts: qcom: msm8994-angler: Enable power key, volume up/down") (will be in kernel 6.14)
- Testing of c910544d22347 ("arm64: dts: qcom: msm8994: Describe USB interrupts") (will be in kernel 6.14)
- WIP USB support for msm8994
Modernize ocfs2 by goldwynr
Ocfs2 has gone into a stage of neglect and disrepair. Modernize the code to generate enough interest.
Goals: * Change the mount sequence to use fscontext * Move from using bufferhead to bio/folios * Use iomap * Run it through xfstests
Create DRM drivers for VESA and EFI framebuffers by tdz
Description
We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.
Goals
- Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
- Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.
New openSUSE-welcome by lkocman
Project Description
Let's revisit our existing openSUSE welcome app.
My goal was to show Leap 16 in a new coat. Welcome app adds to the first time use experience. We've recently added donation button to our existing welcome.
Some things that I recently wanted to address were EOL and possibly upgrade notification.
I've already done some experiments with mint welcome app, but not sure if it's better than the existing one.
There is also a PR to rework existing app https://github.com/openSUSE/openSUSE-welcome/pull/36 (this should be considered as an option too)
Goal for this Hackweek
New welcome app, possibly with EOL notification for Leap.
1) Welcome application(s) with (rebrand changes) maintained under github.com/openSUSE
2) Application is submitted to openSUSE:Factory && openSUSE:Leap:16.0
3) Updated needles in openQA (probably post hackweek)
Resources
Reddit discussion about the best welcome app out there.
Github repo for the current welcome app.
Create a DRM driver for VGA video cards by tdz
Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.
VGA has a number of limitations, which make this project interesting.
- There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
- Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
- VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.
The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.
Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA
Finish gfxprim application multiplexor (window manager) by metan
Project Description
I've implemented drivers for a few e-ink displays during the last hackweek and made sure that gfxprim widgets run nicely on e-ink as well. The missing piece to have a portable e-ink computer/reader/music player/... is a application that can switch between currently running applications and that can start new applications as well. Half of the solution is ready, there is a proxy gfxprim backend where applications render into a piece of a shared memory and input events (e.g. keyboard, mouse) can be multiplexed. What is missing is an interface (possibly touchscreen friendly as well) to make it user friendly.
Goal for this Hackweek
Make nekowm usable "window manager".
Resources
Create a DRM driver for VGA video cards by tdz
Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.
VGA has a number of limitations, which make this project interesting.
- There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
- Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
- VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.
The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.
Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA
Create DRM drivers for VESA and EFI framebuffers by tdz
Description
We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.
Goals
- Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
- Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.