https://wiki.archlinux.org/api.php?action=feedcontributions&user=Atomicpookavirus&feedformat=atomArchWiki - User contributions [en]2024-03-30T04:09:19ZUser contributionsMediaWiki 1.41.1https://wiki.archlinux.org/index.php?title=Uvesafb&diff=255038Uvesafb2013-04-24T04:17:58Z<p>Atomicpookavirus: /* GRUB2 */</p>
<hr />
<div>[[Category:Laptops]]<br />
[[it:Uvesafb]]<br />
[[zh-CN:Uvesafb]]<br />
[[Category:Eye candy]]<br />
<br />
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. It may seem foolish to emulate x86 code on a x86, but this is important if one wants to use the framebuffer code on other architectures (notably non-x86 ones). A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
# Proper blanking and hardware suspension after delay<br />
# Support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
==Installation==<br />
Install the uvesafb package:<br />
# pacman -S v86d<br />
<br />
==Prepare the System==<br />
===Bootloader Modifications===<br />
Remove any framebuffer-related kernel boot parameter from the bootloader configuration to disable the old vesafb framebuffter for loading.<br />
<br />
====GRUB====<br />
Remove all references to {{Ic|vga<nowiki>=</nowiki>xxx}} from kernel lines in {{ic|/boot/grub/menu.lst}} to allow correct operation of uvesafb.<br />
<br />
====GRUB2====<br />
First edit {{ic|/etc/default/grub}} commenting the {{ic|1=GRUB_GFXPAYLOAD_LINUX=keep}} line.<br />
<br />
Then regenerate {{ic|grub.cfg}} via the standard script:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
In some cases you will have to disable [[KMS]] before attempting to boot into framebuffer: failure to do so would result in a pitch-black screen, leaving no option but to restart the machine with {{Keypress|Ctrl+Alt+Del}}. For [[Intel]] cards, this is accomplished by appending {{ic|<nowiki>i915.modeset=0</nowiki>}} to [[GRUB]]'s entry.<br />
<br />
Warning: disabling KMS may break Xorg.<br />
<br />
===Add a v86d HOOK===<br />
Add the v86d hook to HOOKS in {{ic|/etc/mkinitcpio.conf}} to allow uvesafb to take over at boot time.<br />
HOOKS="base udev v86d ..."<br />
<br />
==Configure uvesafb==<br />
===Define a Resolution===<br />
The options for uvesafb are defined in {{ic|/usr/lib/modprobe.d/uvesafb.conf}} which is the default file installed by the {{Pkg|v86d}} package.<br />
<br />
# This file sets the parameters for uvesafb module.<br />
# The following format should be used:<br />
# options uvesafb mode_option=<xres>x<yres>[-<bpp>][@<refresh>] scroll=<ywrap|ypan|redraw> ...<br />
#<br />
# For more details see:<br />
# http://www.kernel.org/doc/Documentation/fb/uvesafb.txt<br />
#<br />
options uvesafb mode_option=1280x800-32 scroll=ywrap<br />
<br />
To prevent your customizations being overwritten when the package is updated, make any changes and copy this file to {{ic|/etc/modprobe.d/uvesafb.conf}} and then add an entry in the FILES section of {{ic|/etc/mkinitcpio.conf}} pointing to your configuration file, like so:<br />
FILES="/etc/modprobe.d/uvesafb.conf"<br />
<br />
===Regenerate initramfs Images===<br />
Changes are commited via booting into the initramfs images. Thus, users need to regenerate the initramfs images for the kernel(s). The following example assumes the default Arch Linux kernel:<br />
# mkinitcpio -p linux<br />
<br />
===Reboot===<br />
Reboot the system to see the changes.<br />
<br />
==Listing Resolutions==<br />
A list of possible resolutions can be generated via the following command:<br />
$ cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes<br />
<br />
Users can modify {{ic|/usr/lib/modprobe.d/uvesafb.conf}} with any entry returned.<br />
<br />
Either of following commands can be used to show the current framebuffer resolution as a sanity check to see that settings are honored:<br />
$ cat /sys/devices/virtual/graphics/fbcon/subsystem/fb0/virtual_size<br />
<br />
$ cat /sys/class/graphics/fb0/virtual_size<br />
<br />
==Uvesafb compiled into the kernel==<br />
{{Expansion}}<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from {{ic|/etc/rc.local}}. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>. Please note that this solution is not viable in the case you want to combine uvesafb with 915resolution as suggested below.<br />
<br />
==The homepage of uvesafb==<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed information (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some information in the site assumes that uvesafb is compiled in the kernel, while it is a module in the Arch Linux stock binary kernel).<br />
<br />
==Uvesafb and 915resolution==<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggy BIOS, which does not support the main, native resolution of the wide screen! For this reason, 915resolution was created to patch the BIOS at boot time and allow the X server to use the widescreen resolution. Nowadays, the X server is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
===915resolution-static===<br />
In this scenario, 915resolution needs to be compiled statically (since it is going to be in an initramfs, it can not be linked to external libraries). Thus you CAN NOT use the 915resolution package in the [community] repo. Look instead for {{AUR|915resolution-static}} in the AUR. It compiles 915 resolution statically and provides a 915 resolution hook, so you can run 915resolution before loading uvesafb and get the patched resolution. So install 915resolution-static via makepkg and [[pacman]].<br />
<br />
===The resolution===<br />
You need to edit the 915resolution hook in order to define the BIOS mode you want to replace and and the resolution you want to get. You can get information about all the options for 915resolution with:<br />
<br />
915resolution -h<br />
<br />
So edit {{ic|/lib/initcpio/hooks/915resolution}} and modify the options for 915resolution:<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
In the default, 5c is the code of the BIOS mode to replace. You can get a list of the available BIOS video modes with {{Ic|915resolution -l}}.<br />
{{Note|You want to choose the code of a mode that you ''DO NOT'' need (neither in the framebuffer nor in X), because 915resolution will replace it with a new user-defined mode. In the above example, {{Ic|1280 800}} is the new desired resolution.}}<br />
<br />
===The HOOKS array===<br />
Add the 915resolution hook and, after it, the v86d hook to HOOKS in {{ic|/etc/mkinitcpio.conf}}. Put them before the hooks for the keymap, the resume from suspension and the filesystems.<br />
HOOKS="base udev 915resolution v86d ..."<br />
<br />
Then you need to regenerate your initramfs with mkinitcpio (adjust the following command to your setup):<br />
<br />
mkinitcpio -p linux<br />
<br />
==Troubleshooting==<br />
===Uvesafb cannot reserve memory===<br />
<br />
Check if you forgot to remove any {{Ic|vga<nowiki>=</nowiki>xxx}} kernel parameter -- this overrides the UVESA framebuffer with a standard VESA one.<br />
<br />
===pci_root PNP0A08:00 address space collision + Uvesafb cannot reserve memory===<br />
<br />
This occurs on the Acer Aspire One 751h with the 2.6.34-ARCH kernel; whether it also occurs on other systems is unknown. Even without another framebuffer interfering with the uvesafb setup, uvesafb cannot reserve the necessary memory region.<br />
<br />
You can fix this issue by adding the following to the kernel parameters in your bootloader's configuration.<br />
<br />
pci=nocrs</div>Atomicpookavirushttps://wiki.archlinux.org/index.php?title=Gamepad&diff=72243Gamepad2009-07-16T23:30:51Z<p>Atomicpookavirus: The Gento Wiki article no longer exists. I removed the link.</p>
<hr />
<div>[[Category:Input devices (English)]]<br />
[[Category:HOWTOs (English)]]<br />
Joysticks can be a bit of a hassle to get working in Linux. Not because they are poorly supported, but simply because you need to determine which modules to load to get your joystick working, and it's not always very obvious!<br />
<br />
= Setup =<br />
== Determining Which Modules You Need ==<br />
For an extensive overview of all joystick related modules in Linux, you will need access to the Linux kernel sources -- specifically the Documentation section. Unfortunately, pacman kernel packages don't include what we need. If you have the kernel sources downloaded, have a look at <code>Documentation/input/joystick.txt</code>. You can browse the kernel source tree at [http://kernel.org/ kernel.org] by clicking the "C" (current changesets) link, then clicking the "tree" link near the top. Here's a link to the [http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.17.y.git;a=blob;h=d53b857a3710ccdde5bc504f212993dcb10a20be;hb=d2350c2ad1463a973b586cadb49c2fa0c83089b8;f=Documentation/input/joystick.txt Documentation from kernel 2.6.17.11].<br />
<br />
Some joysticks need specific modules, such as the Microsoft Sidewinder controllers (<code>sidewinder</code>), or the Logitech digital controllers (<code>adi</code>). Many older joysticks will work with the simple <code>analog</code> module. If your joystick is plugging in to a gameport provided by your soundcard, you will need your soundcard drivers loaded - however, some cards, like the Soundblaster Live, have a specific gameport driver (<code>emu10k1-gp</code>). Older ISA soundcards may need the <code>ns558</code> module, which is a standard gameport module.<br />
<br />
As you can see, there are many different modules related to getting your joystick working in Linux, so I couldn't possibly cover everything here. Please have a look at the documentation mentioned above for details.<br />
<br />
==Loading the Modules==<br />
You need to load a module for your gameport (<code>ns558</code>, <code>emu10k1-gp</code>, <code>cs461x</code>, etc...), a module for your joystick (<code>analog</code>, <code>sidewinder</code>, <code>adi</code>, etc...), and finally the kernel joystick device driver (<code>joydev</code>). Add these to your <code>/etc/rc.conf</code>, or simply modprobe them. The <code>gameport</code> module should load automatically, as this is a dependency of the other modules.<br />
<br />
==Testing Your Configuration==<br />
Once the modules are loaded, you should find a new device: <code>/dev/input/js0</code>. You can simply <code>cat</code> the device to see if it works - move the stick around, press all the buttons. I found my Logitech Thunderpad Digital had two buttons that weren't working with the <code>analog</code> module. After reading some docs, I saw there was a specific <code>adi</code> module for this controller. The moral of the story is, if it doesn't work the first time, don't give up, and read those docs thoroughly! I couldn't get anything working at all until I found that documentation.<br />
<br />
==USB Joysticks==<br />
You need to get USB working, and then modprobe your joystick driver, which is <code>usbhid</code>, as well as <code>joydev</code>. <br />
If you use a usb mouse or keyboard, <code>usbhid</code> will be loaded already and you just have to load the <code>joydev</code> module.</div>Atomicpookavirus