[TMG] Re: no Thai KBD on slackware 13.0 (fwd)
supat at supat.eu.org
supat at supat.eu.org
Thu Sep 17 08:58:40 ICT 2009
I fwd to thai-l to make TMG to use slackware with full TH support and get
rid off bg slavery.
---------- Forwarded message ----------
Date: Thu, 17 Sep 2009 08:54:08 +0700 (ICT)
From: supat at supat.eu.org
To: Patrick J. Volkerding <volkerdi at slackware.com>
Subject: Re: no Thai KBD on slackware 13.0
Hi PAT,
Thank you so much for your kind help.
I can use TH KBD now by adding:
Option "AllowEmptyInput" "false"
Option "AutoAddDevices" "false"
Option "AutoEnableDevices" "false"
To use old style Xorg.
Regards,
supat
On Wed, 16 Sep 2009, Patrick J. Volkerding wrote:
> supat at supat.eu.org wrote:
>>
>> Hi PAT,
>>
>> Today I found that under X11 I cannot use Thai keyboard.
>>
>> At this moment I try to get full Xorg and will compile it to see what is
>> going wrong.
>>
>> Please let me know if you can help me on this.
>
> Did you take note of the CHANGES_AND_HINTS file where it talks about editing
> 10-keymap.fdi to set the keymap? Now that X.Org defaults to using HAL to
> manage input devices, that's where the setting needs to go.
>
> Take care,
>
> Pat
>
part of SLAK HINT was copy here:
*** OTHER NOTABLE CHANGES AND HINTS ***
l/dbus moved to a/dbus
New system user accounts:
oprofile (uid=51)
New system group accounts:
oprofile (gid=51)
dialout (gid=16)
netdev (gid=86)
The Slackware installer now uses udev to initialize your hardware,
including
the network interface card(s). This has positive consequences for
network
installations (using NFS, FTP, HTTP or SMB). You no longer have to run
the
'pcmcia' and 'network' scripts prior to running 'setup' - the network
interface will be created and intialized by udev. If a DHCP server is
found on your local network, the setup program will let you choose
between
automatic configuration of your network interface using DHCP or
specifying
a static IP address. Using udev, the commandline for fully unattended
configuration and startup of the dropbear SSH server has changed
slightly.
Suppose you want to boot the 'hugesmp' kernel, use DHCP for interface
eth0,
and you have a us-english keyboard layout: the commandline to auto-start
the SSH daemon in the installer would become:
hugesmp.s kbd=us nic=auto:eth0:dhcp
Note: if you do not want to use udev, the "auto" keyword in that example
commandline must be replaced with the actual name of the network module
for
your card. If you do not want to use udev, you must add the parameter
"noudev" to the command line that boots the Slackware installer, and the
original ("old") Slackware hardware configuration scripts will be used.
Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock
generic kernels. You will need to create an initrd in order to boot
the generic kernels - see /boot/README.initrd for instructions.
The huge kernels are primarily intended as "installer" and "emergency"
kernels in case you forget to make an initrd. For most systems, you
should use the generic SMP kernel if it will run, even if your system is
not SMP-capable. Some newer hardware needs the local APIC enabled in
the
SMP kernel, and theoretically there should not be a performance penalty
with using the SMP-capable kernel on a uniprocessor machine, as the SMP
kernel tests for this and makes necessary adjustments. Furthermore, the
kernel sources shipped with Slackware are configured for SMP usage, so
you
won't have to modify those to build external modules (such as NVidia or
ATI proprietary drivers) if you use the SMP kernel.
If you decide to use one of the non-SMP kernels, you will need to follow
the
instructions in /extra/linux-2.6.29.6-nosmp-sdk/README.TXT to modify
your
kernel sources for non-SMP usage. Note that this only applies if you
are
using the Slackware-provided non-SMP kernel - if you build a custom
kernel,
the symlinks at /lib/modules/$(uname -r)/{build,source} will point to
the
correct kernel source so long as you don't (re)move it.
As usual, there are changes in udev packaging that need mentioning...
As with 12.2, the system udev rules now reside in /lib/udev/rules.d/
instead of /etc/udev/rules.d/ in older versions. There should never be
a reason to edit anything in /lib/udev/rules.d/, so if you think you
have
a case where this is required, either you're wrong or it needs to be
addressed in the upstream source. However, you can override default
rules
by placing one with an identical name inside /etc/udev/rules.d/ The
rules
files in /etc/udev/rules.d/ are still intended to (maybe) be edited as
needed by local system administrators, and as such, the rules for
optical
and network devices will still be placed there.
Also, be sure to have the new dialout group added to your system, or
udev
will kindly remind you in the system logs...
Due to the upgrade of kde from 3.5.10 to 4.2.4, you will need to move your
existing $HOME/.kde/ out of the way (either completely remove it or back
it up somewhere else if you think you might need it again for whatever
reason); otherwise, you will almost surely experience odd configuration
problems with kde applications.
If mailto: links don't work properly (or at all) in firefox, you may have
to remove an existing $HOME/.mozilla/mimeTypes.rdf file and restart
Firefox.
If you are unable to access the cups configuration web interface from your
browser, you may have to blacklist the ipv6 module and reboot. This is
not an acceptable solution, of course, but it's the only one we have at
the moment.
HP multifunction printer/scanners require that your user account be a
member
of the "lp" group for hp-toolbox to work properly, and to use the
scanner
portion of some (all?) units, you'll need to be a member of the "lp"
group.
This is because hplip's udev rules set the device with group "lp"
ownership.
HAL is not new anymore, but here are a few notes related to it:
1. User accounts with permission to mount removable devices must be in
at
least the "plugdev" group.
2. User accounts with permission to do power-management tasks, such as
suspend, hibernate, reboot, and shutdown, via HAL methods should be
in
the "power" group.
3. HAL will honor settings in /etc/fstab if a device is present there,
so
you could technically have removable devices defined in /etc/fstab,
but
if the fstab settings do not allow normal users to mount them (with
the
"user" or "users" option), then HAL/dbus will not allow them to be
mounted either. In other words, for example, if your fstab line for
the
cdrom/dvd drive includes the "owner" option, you will not be able to
mount it as a normal user.
4. If you find a need for modified fdi files, those should be placed in
the
relevant directories in /etc/hal/ instead of /usr/share/hal/
If you notice Xfce's Terminal and perhaps some other applications being
drawn
very slowly in X, then you should try explicitly disabling the Composite
extension in /etc/X11/xorg.conf, or set XLIB_SKIP_ARGB_VISUALS=1 in your
environment prior to starting X. For more information on this, see:
http://bugzilla.xfce.org/show_bug.cgi?id=2792
We've also gotten a report of some other things (such as VirtualBox)
that
might benefit from this.
Speaking of Xorg, the version of Xorg shipped with Slackware 13.0 will not
(in most cases) require an /etc/X11/xorg.conf file at all.
Configuration of
input devices and such is handled by HAL, and the X server
autoconfigures
everything else. You can still create an xorg.conf file if you wish, or
you
can create a minimal xorg.conf with only the specific contents that you
wish
to override (as an example, to use a binary-only video driver).
Due to removed drivers and other such changes, it's quite possible that
your
old xorg.conf will not work correctly with this version of Xorg.
If you need to use a non-US keyboard layout, then copy the file located at
/usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to
/etc/hal/fdi/policy
and edit it to suit your needs. Have a look at the contents of that
file
for an example and more information. If you prefer to do this the "old"
way
using /etc/X11/xorg.conf, then you can use "X -configure" or "xorgsetup"
to
generate an xorg.conf, then add the following lines to the "ServerFlags"
section to disable input device hotplugging via HAL:
Option "AllowEmptyInput" "false"
Option "AutoAddDevices" "false"
Option "AutoEnableDevices" "false"
This is also relevant if you prefer to disable HAL completely for
whatever
reason.
If you are using input hotplugging via HAL and a synaptics touchpad, then
you
might need to copy /usr/share/hal/fdi/policy/11-x11-synaptics.fdi to
/etc/hal/fdi/policy/ and edit it to suit your needs. You can also use
synclient(1) to make changes "on the fly."
If you want to try the new kernel mode setting (KMS), you don't have to
build a custom kernel; add this to your kernel's lilo stanza:
append = "i915.modeset=1"
If you are using a KVM switch, you might experience problems with the
mouse
when switching from one system to another. If so, you probably need to
be
using the imps protocol for the psmouse driver, and that's a simple
edit:
uncomment the following line in /etc/modprobe.d/psmouse.conf:
#options psmouse proto=imps
Next, unload and reload the psmouse module (do this as root):
modprobe -r psmouse ; modprobe psmouse
If you have set up an encrypted root partition, you will need to have
access
to your keyboard in order to type the passphrase. This may require you
to
add the uhci-hcd and usbhid modules to your initrd image if you have a
USB
keyboard. Also note that if you are using a non-US keyboard, you can
use the
'-l' parameter to the 'mkinitrd' command in order to add support for
this
keyboard to your initrd.
If you have permission errors when attempting to burn a cdrom or dvd
image,
such as the following:
/usr/bin/cdrecord: Operation not permitted. Cannot send SCSI cmd via
ioctl
then cdrecord almost certainly needs root privileges to work correctly.
One potential solution is to make the cdrecord and cdrdao binaries suid
root,
but this has possible security implications. The safest way to do that
is
to make those binaries suid root, owned by a specific group, and
executable
by only root and members of that group. For most people, the example
below
will be sufficient (but adjust as desired depending on your specific
needs):
chown root:cdrom /usr/bin/cdrecord /usr/bin/cdrdao
chmod 4750 /usr/bin/cdrecord /usr/bin/cdrdao
If you don't want all members of the 'cdrom' group to be able to execute
the
two suid binaries, then create a special group (such as 'burning' which
is
recommended by k3b), use it instead of 'cdrom' in the line above, and
add
to it only the users you wish to have access to cdrecord and cdrdao.
If you have compilation errors that look something like this:
/usr/include/asm-generic/fcntl.h:117: error: redefinition of 'struct
flock'
/usr/include/bits/fcntl.h:142: error: previous definition of 'struct
flock'
/usr/include/asm-generic/fcntl.h:140: error: redefinition of 'struct
flock64'
/usr/include/bits/fcntl.h:157: error: previous definition of 'struct
flock64'
See the following link for some pointers on fixing it:
http://www.mail-archive.com/blfs-dev@linuxfromscratch.org/msg08942.html
Input methods for complex characters (CJK, which is shorthand for Chinese,
Japanese, Korean) and other non-latin character sets have been added.
These
input methods use the SCIM (Smart Common Input Method) platform.
The environment variables for SCIM support are set in
/etc/profile.d/scim.sh
The requirements for getting SCIM input methods to work in your X
session
are as follows:
(1) Use a UTF-8 locale. Look in /etc/profile.d/lang.sh for setting your
language to (for instance) en_US.UTF-8. As a word of warning: maybe
you
should leave root with a non-UTF-8 locale because you don't want
root's
commands to be misinterpreted. You can add the following line to
your
~/.profile file to enable UTF-8 just for yourself:
export LANG=en_US.UTF-8
(2) Make the scim profile scripts executable. These will setup your
environment correctly for the use of scim with X applications. Run:
chmod +x /etc/profile.d/scim.*
(3) Start the scim daemon as soon as your X session starts. The scim
daemon
must be active before any of your X applications. In KDE, you can
add a
shell script to the ~/.kde/Autostart folder that runs the command
"scim -d". In XFCE you can add "scim -d" to the Autostarted
Applications.
If you boot your computer in runlevel 4 (the graphical XDM/KDM
login)
you can simply add the line "scim -d" to your ~/.xprofile file.
This gives you a Desktop Environment independent way of starting
scim.
When scim is running, you will see a small keyboard icon in your system
tray.
Right-click it to enter SCIM Setup. In 'Global Setup' select your
keyboard
layout, and you are ready to start entering just about any language
characters you wish! Press the magical key combo <Control><Space>
in order to activate or deactivate SCIM input. The SCIM taskbar in the
desktop's corner allows you to select a language. As you type, SCIM will
show
an overview of applicable character glyphs (if you are inputting complex
characters like Japanese).
If you are using the pinentry-gtk2 interface (for entering passphrases
with
gpg-agent), be aware that there is a bug in the way scim-bridge and the
pinentry-gtk2 interact. The result is that keyboard input does not
register
with pinentry-gtk2. For the time being, either change the
/usr/bin/pinentry
symlink to use the qt or curses frontend, or don't use scim.
If you have an older machine (with a BIOS released prior to 2001) and it
will
not power off on shutdown, try adding this to your kernel's lilo stanza:
append = "acpi=force"
If you have a Dell Optiplex 760 (or perhaps some other machine that has
the
newer ICH10 chipset), and it won't boot, try one of these:
1. Update the BIOS image to at least A03
2. Turn C-States control off in the BIOS
3. Boot with "hpet=disabled"
If your wireless and/or bluetooth radios are not turned on by default
after
booting up, you might need to load the rfkill-input module. If that
solves
the problem for you, edit /etc/rc.d/rc.modules.local or
/etc/rc.d/rc.local
to load the module on boot, or create /etc/modprobe.d/rfkill.conf and
put
the following line in it:
install rfkill /sbin/modprobe -i rfkill ; /sbin/modprobe -i
rfkill-input
More information about the Thai-l
mailing list