@Hélio, only thing I did was upgrade to 16.04 (clean install), copy my
xkb file over and load it (xkbcomp $HOME/.xkb/xkb-map $DISPLAY). That's
it.
Well, it *does* get loaded on each boot via .bashrc (as noted in post
14) when a terminal is auto-opened (put in startup prefs) so not sure it
will
Bug is gone in 16.04!
.Xmodmap (which IS deprecated) still needs to be converted to xkb (post
14,
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1243642/comments/14),
but then everything works as before: keyboard map reloads automatically
after any number of suspend/hibernate cycles.
Joined this bug thread, then found the cause of the problem -- in my
case at least.
The connection from PC through AVR to TV was marginal (due to cable
length, one coupling connector, cable quality, routing, etc.). The
problem was undetectable except by these no speaker allocation for ELD
Yes, different. Editing those system-level files affects keyboard
mapping for ALL users. But this bug is about .Xmodmap, which is
per-user. My post noted that even xkb maps are lost on suspend/sleep.
Converting .Xmodmap files to xkb is straightforward. After manually
loading the desired
This bug remains, and the problem is just as bad after converting from
an .Xmodmap file to an xkb map: THE FILE MUST BE MANUALLY RELOADED ON
AWAKENING.
- A script in /etc/pm/sleep.d does not work.
- A script on the desktop does not work.
- Tearing hair out does not work.
Auto-loading the map
Just checked and the setting still exists in latest 12.04.3, but it has
no effect at all.
Upgrading to 14.04 in two months -- hopefully it will be functional in
the new release.
This is a valuable feature. It really needs to be restored.
--
You received this bug notification because you are a
This fired me up to get rid of libav and install the real ffmpeg.
It's not necessary to compile. See my post here:
http://askubuntu.com/a/373509/165265
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libav in Ubuntu.
Competition between the two teams (ffmpeg-libav) undoubtedly makes
each package better.
Given the robust development happening in each camp, should Canonical
really be picking the winner/loser here to begin with?
Personally, I don't like the symlinks to a lesser release. My
inclination is to
8 matches
Mail list logo
