as you might know kernel module cfg80211 has a parameter to set the
parm: ieee80211_regdom:IEEE 802.11 regulatory domain code
By default the following channels are allowed:
Channel 01 : 2.412 GHz
Channel 02 : 2.417 GHz
Channel 03 : 2.422 GHz
Channel 04 : 2.427 GHz
Channel 05 : 2.432 GHz
Channel 06 : 2.437 GHz
Channel 07 : 2.442 GHz
Channel 08 : 2.447 GHz
Channel 09 : 2.452 GHz
Channel 10 : 2.457 GHz
Channel 11 : 2.462 GHz
Channel 36 : 5.18 GHz
Channel 40 : 5.2 GHz
Channel 44 : 5.22 GHz
Channel 48 : 5.24 GHz
Channel 52 : 5.26 GHz
Channel 56 : 5.28 GHz
Channel 60 : 5.3 GHz
Channel 64 : 5.32 GHz
This means, I am missing some channels here in good old germany (e.g. 12
& 13). Apparently the US domain seems to be a subset of the EU domain,
so I can not use channels that are prohibited by the EU domain.
So wouldn't it make sense to ask for the current locale and set the
parameter in /etc/modprobe.d when updating/installing either the kernel
https://launchpad.net/x-kit - DontZap is an application written in
Python which relies on X-Kit and allows users to set the "DontZap"
option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server has
been disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is
crucial that Ctrl-Alt-Backspace be enabled by default. There are times
when your KVM has lost mouse control or X is in a tight loop and
something like Ctrl-Alt-Backspace can save the situation. This is much
more common than the uncommon cases that are illustrated as to why this
has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users
or others that find themselves in conflict with Java expressions can
just disable it for their very limited purpose.
python-paver is a program and library to make building and installing
python modules easy. We currently have 0.8 in F9, F10, and EPEL. 1.0
is built for rawhide. 0.8 and 1.0 are API incompatible. I'm going to
update to the 1.0 version in the stable releases after it proves itself
in rawhide due to two things:
1) There's a number of bugs in 0.8 that won't be fixed because 1.x is
where work is being done.
2) It's a mess to try to support both paver-1.0 and paver-0.8 in one
pavement.py file. My efforts to do so show that it's not possible to
have all the functionality of 1.0 in 0.8.
If any project we're packaging is using paver to build and cannot
upgrade to 1.0, let me know so I can either help with porting the
buildscripts or start the review process on a python-paver0.8 compat
The wiki freeze is scheduled for tomorrow. If you plan to add some release
notes content to the wiki, time is getting short.
If there are items you think need more content, but you aren't comfortable
with the wordsmithing, leave some content in the wiki and the Docs folks
will be happy to clean up the prose.
Following the wiki freeze we still can make changes in the xml, so if
something comes up that should change the release notes, email myself or
Ryan Lerch and we will make the changes.
Be it hereby announced that this Wednesday, the first of the glorious
month of April (ignore Eliot, he was a douche), shall be the Test Day
for the radeon video driver. Which is used, as you may already have
deduced, for ATI Radeon (and FireGL) video cards. All of 'em.
If you have such a card, please make all appropriate effort to attend -
in #fedora-qa on Freenode, whenever counts as Wednesday daytime for you
(there should be someone, either myself, Dave or someone else from the
QA department, around all day).
The Wiki page is replete with instructions and test cases and a results
table, and will shortly contain up-to-date live CD images (for now, the
links point to the Nouveau test day live images, which don't have the
latest changes from Rawhide). So it's very easy to test without needing
a permanent install of Rawhide or any permanent changes to your system.
We really need testing with as broad as possible a range of Radeon
cards, so if you have one, please do come out and do the tests! Thanks.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
I've raised a number of video bugs, but after some advice on this one....
When playing flash videos on a Thinkpad T60p core duo @ 2.16 Ghz, ATI
V5200 (R500 series), compiz enabled I'm seeing v. high CPU consumption from:
This is with BBC iplayer (http://www.bbc.co.uk/iplayer -- UK only)
running 1/4 screen (full is 1600x1200).
This is stuttery, but trying to play full screen just results in a
this is with CPU power mode at "performance" - so full 2.16Ghz
As a comparison, a 720x480 wmv 24bpp 254 kbps played with mplayer, "xv"
consumes ~15%/10% (2nd figure is mplayer itself) cpu. With "x11" mode it
Known issue? Should I raise a new bugzilla? Or is it more likely an
adobe implementation issue?
Note that for those in the UK "BBC iPlayer" really is a killer app. It's
on WII, mobile, web and allows catchup of most of BBC's output for ~1
month PVR style either via streaming or download.