It would be good if we would start with collection release notes
snippets for 11.2 now. Do not hesitate to provide input!
Here is some background information:
http://en.opensuse.org/Release_Notes
--
Karl Eichwalder
R&D / Documentation
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Folks -
In yesterday's discussion about the future of SaX2 it has been requested
that changes that will affect users in the future are communicated to
the openSUSE community early. KMS (kernel mode setting) integration would
be such a feature, thus I would like to announce this here and
one step further dive into a technical discussion about a possible
solution.
Furthermore test packages are available to try things out on Factory.
I would like to encourage people interested in development and technical
discussions in general to participate in the discussion and the development
efforts.
Kernel Modesetting (KMS)
========================
All of you who are using a graphical desktop on Linux have been using
the X Window Sytem.
The X Window System Server (XServer) is the instance which receives
requests from your desktop applications to draw all the widgets (windows,
buttons, images etc.) you see on your desktop. It also processes input
from your keyboard and mouse and sends them to applications as events.
Traditionally on Linux the XServer does not only draw images to the screen
(ie writes them to some sort of frame buffer) but it is in charge of
initializing, setting up and driving the graphics hardware.
This paradigm which has been true since the X Window System has been
ported to Linux is about to change: Much of the initialization, set up
(video mode setting) and control of the graphics hardware is about to
move to the Linux kernel.
There are a number of advantages to this:
- A central instance is in charge of the graphics hardware, other
user mode applications (not just the Xserver) can take advantage of mode
setting.
- The Xserver will no longer require full root privileges as it doesn't
talk to the hardware directly any more.
- Faster boot process: The Xserver doesn't need to (re)initialize the graphics
hardware any more, this is all done by the kernel very early in the boot
cycle.
- Smoother (flicker free) boot experience: The screen doesn't flicker and
changes resolution any more when the Xserver starts.
- One central entity is in charge and manages the resources of the graphics
hardware - like the video memory which makes sharing of these resources
between several applications (like Xserver and several DRI (Direct Rendering
3D) applications much easier.
KMS is integrated in the DRM drivers.
In the near future most graphics driver will switch to KMS:
- Intel already ships a fully working KMS driver. Future Intel chipsets will
be supported by the KMS driver only.
- KMS in the Radeon DRM driver is still work in progress but it is already
working well on some chipsets.
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA
chipsets.
The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the
near future.
Integration in openSUSE
=======================
Now this begs the question what we have to do to integrate it into openSUSE.
Originall I had plans to look into this for openSUSE 11.2 already - but then
I got side tracked by other stuff it fell on the floor and noone else beat me
to it either ... oh well.
Now I had the chance to play around with KMS a little and came up with some
ideas and a proof of concept.
It turned out that the changes to openSUSE needed to fully support KMS are
quite small. Key is to load the KMS aware DRM driver as early as possible in
the boot process to avoid video mode changes later in the boot cycle -
preferrably in the initrd.
The Boot Process
----------------
On openSUSE the boot loader is configured for two boot scenarios: default
and failsafe. The user can select the failsafe boot scenario in case the
default scenario does not work for him. In the failsafe scenario certain
features are deactivated which have shown to cause problems on some systems.
Since KMS is a new feature it is a candidate for deactivation during a
failsafe boot. Instead the system should then boot into the VESA framebuffer
mode. Should this also fail the kernel will automatically fall back to a VGA
text mode.
To disable KMS on boot a new boot parameter is introduced: 'nomodeset'.
This parameter is to the boot command line for the failsafe mode.
The user may add this parameter by hand for any other boot mode.
The kernel command line is parsed in initrd and an appropriate
entry is created in /etc/modprobe.d/options. Furthermore the graphics
driver module and - if required - the agp module(s) are added in the
correct order (agp modules first) to the list of modules to be loaded
initially.
Changes to individual packages
==============================
1. yast2-bootloader & perl-Bootloader
-------------------------------------
The boot parameter 'nomodeset' is added to the failsafe boot
paramter lists in each of the modules. (I have not been able
to find out which module provides the entry relevant for which
situation, therefore I've whacked both.)
yast2-bootloader updates the variable FAILSAFE_APPEND in
/etc/sysconfig/bootloader appropriately.
2. kernel-source
----------------
To use KMS for a certain DRM driver the kernel config option
CONFIG_DRM_<driver_name>_KMS needs to be set to 'y'.
At the moment we will support KMS only for Intel hardware,
thus only the variable CONFIG_DRM_I915_KMS needs to be changed.
In the sample build this has been enabled for the -default,
-desktop, -pae, -debug, -trace and -vanilla kernels for the
i386 and x86_64 platforms.
The kernel boot splash has already been fixed for KMS for
openSUSE 11.2.
3. mkinitrd
-----------
This package writes the initrd file. To add KMS support to the initrd
mkinitrd needs to perform the following tasks:
1. Check the sysconfig variable NO_KMS_IN_INITRD, if set, don't attempt to
install a KMS DRM capable driver.
2. Obtain a list of PCI devices installed on the system.
3. a. In the list of PCI devices identify those devices which are of class VGA
and look for a matching driver. b. Before a driver is matched check the
PCI vendor, device, subvendor and
subdevice ids against a blacklist in /etc/kms/blacklist should this file
exist. This file contains one vendor, device, subvendor and subdevice
id per line, '*' serves as a wildchar, trailing wildchars may be
ommitted, '#' at the beginning of a line serves as a comment.
c. Use the standard modprobe alias mechanism to find a matching DRM driver
module. This way standard blacklistings of kernel modules will be
honored and update modules will be searched if they are available. KMS
capable DRM drivers provide an alias list (in contrast to non-KMS
capable DRM drivers which are to be loaded explicitely by the Xserver).
d. If a driver is found check for a black listing in
/etc/kms/<driver_name>.blacklist. The same rules as in 3 b. apply.
4. If a KMS capable DRM driver is found search for an agp driver:
a. Obtain a list of all known agp drivers for the specific kernel
and collect their alias lists.
b. Match all installed PCI devices against the alias lists of each
agp driver. If a match is found add the driver to the lists of modules
to be loaded. Make sure that this driver is loaded prior the the DRM
driver.
Two scripts setup-kms.sh and boot-kms.sh are added to mkinitrd.
The former performs the tasks listed above, the latter provides the
required module dependencies in the required order, parses the boot
command line for the 'nomodeset' option and adds the apropriate entry to
/etc/modprobe.d/options.
The linuxrc script is extended to search the boot command line for
<drivername>.<option>=* strings for each driver loaded in initrd and add
the <option>=* part to /etc/modprobe.d/options.
4. udev
-------
Udev loads any modules which are not loaded by linuxrc scripts directly.
It is possible to let udev load the required DRM and AGP modules provided
it is made sure that this happens in the correct order. Since there is
no explicit dependency of DRM modules to AGP drivers as there is no general
one to one match between the two drivers a udev rule must exist to enforce
the correct order for all cases where a AGP module is required.
This is true for Intel DRM drivers and any other driver for an AGP graphics
chip.
For this a rule file 79-waitfor-agp.rules is added which is run before
80-drivers.rules. It checks if either an Intel graphics (class VGA) device
is processed or if the graphics device is an AGP device. The latter condition
is tested by an auxiliary tool (is_agp) which is passed the kernel name of
the event device. If either condition is true udev will wait for /dev/agpgart
to appear before proceeding to load a DRM driver module.
'is_agp' checks the capabilities flags in the PCI config space of this device
for AGP.
The changes to udev are not strictly required to make KMS work, still they
augment the default module load process
Installation
============
Modified packages for Factory of
- kernel-source,
- mkinitrd,
- yast2-bootloader,
- perl-Bootloader,
- mkinitrd
- udev
can be found in my build service home on OBS under home:eeich:Factory-KMS.
For installation add
http://download.opensuse.org/repositories/home://eeich://Factory-KMS/openSU…
to your installation repository and update the packages in question (going
thru the usual vendor change hassle).
It is advisable to update mkinitrd before updating the kernel. Then when
the kernel is installed the modified mkinitrd will be used and all steps
required to install KMS will be performed.
TODO
====
- The kernel bootsplash sometimes produces wrong colors (WIP). Add KMS
- Add KMS support to the RadeonHD driver.
Cheers,
Egbert.
--
Egbert Eich (Res. & Dev.) SUSE LINUX Products GmbH
X Window System Development
Tel: +49 911-740 53 0 http://www.suse.de
-----------------------------------------------------------------
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
For a while, I've been wondering why we still have glib 1.x and gtk 1.x
(as well as some other part of the GNOME 1.x stack). So today I looked
at this closely, and I think we can work towards removing those
packages.
Why should we remove those libraries? Well, they're not maintained
upstream, and from a security point of view, this can be quite bad.
See below for some analysis on which package it impacts, and what needs
to be done. Please have a look at the list of packages that would get
removed.
Note: I've filed this as https://features.opensuse.org/308601
Thanks,
Vincent
======================================================================
One package needs to be investigated: psx-plugins. All other packages
fall in some category:
Packages that need to be updated or changed
===========================================
fvwm2-gtk:
- this is only a GTK-based alternative for GUI elements in fvwm.
Not critical.
- remove the dependency from fvwm2
icewm:
- simple wm
- make it compile without imlib
mgp:
- tool for presentation
- add patch to move to imlib2 (from Debian, and committed
upstream)
procmeter:
- monitoring tool
- version 3.5 is based on GTK+ 2.x
qiv:
- image viewer
- version 2.2.2 (http://spiegl.de/qiv/) uses GDK 2.x
smilutils:
- tool to convert/edit digital video data (used by kino)
- ported to GTK+ 2.0 in cvs
- other distributions use code from cvs
swami:
- soundfont editor
- uses GTK+ 2.x in svn
- will have a release by next May according to mailing list
TeX-Guy:
- dvi library and utilities
- GTK+ 1.x only needed for xgdvi
- evince can replace xgdvi
usbview:
- display topography of USB devices
- version 1.1 uses GTK+ 2.x
WindowMaker-applets:
- various applets for WindowMaker
- it looks like E-Notes, wmtimer and wmcliphist are the ones
requiring the new libraries
- wmcliphist 1.0 uses GTK+ 2.x
- wmtimer 2.92 uses GTK+ 2.x
- e-notes 0.5 was released in 2001, and there has been no change
since then (we have 0.4). Maybe just drop it?
wmakerconf:
- configuration tool for Window Maker
- versions >= 2.11 use GTK+ 2.x
xteddy:
- some weird app ;-)
- version 2.2 uses imlib 2
xzgv:
- image viewer
- 0.9.x versions use GTK+ 2.x
Packages that can be safely removed
===================================
ami:
- Korean input method
- scim deprecates this
fnlib:
- font rendering for enlightenment
- was used by old versions of enlightenment only, as far as I know
gau:
- Gtk-based Hangul terminal emulator
- shouldn't be needed with a recent terminal and a good Korean
input method
gdk-pixbuf:
- library for images
- can only be used with GTK+ 1.x (was integrated in GTK+ 2.x)
gnome-libs:
- GNOME 1.x libraries
- can only be used with GTK+ 1.x
goom2k4:
- visual effects generator for mp3 players
- not used by anything anymore, as far as I can tell (code was
integrated in gstreamer)
imlib:
- image loading and rendering library
- part of what we want to remove
kanji-lookup:
- simple kanji lookup application
- gucharmap can be used
nicolatter:
- Japanese input method
- scim deprecates this
orbit:
- GNOME 1.x library
- can only be used with GTK+ 1.x
Packages that can be removed, but with no replacement
=====================================================
Those are all dead upstream.
bombermaze:
- game (bomberman/dynablaster clone)
- similar games are available in the games OBS project (xblast,
tomatoes)
gbuffy:
- mailbox watcher
- patch to port to gtk2 available in case someone wants to
resurrect the project:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515274
pcpmon:
- graphical monitor for Performance Co-Pilot
- kmchart is an alternative
soundtracker:
- sound editor
- has been removed from Debian
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everyone -
Occasionally I take a break from kernel hacking. Recently, I was working
on improving the reiserfs support in grub so that it doesn't take
forever to load when there is a journal with outstanding transactions
that need to be replayed.
The thing is that the grub 0.97 code is truly awful. Every file system
implementation has to implement strangely chosen primitives and, outside
of the code itself, has 32k in memory which it has to manage itself and
not exceed. This is the crux of the reiserfs /boot performance issue in
bnc#538795.
On top of that, the upstream grub developers refuse to accept fixes or
features against 0.97, forcing distributors to carry patches around forever.
The good news is that GRUB2 lifts a whole lot of restrictions. It's
modular in design, has a cleaner implementation, and has native support
for more file systems. It supports LVM and MD RAID volumes. It supports
DMRAID volumes (though I'm not sure how well here). The upstream
development community is interested in maintaining it.
The bad news is that it's a boot loader. There may be bugs lurking in
there. That are tough to track down and leave you with an unbootable system.
So who wants to help test? :)
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAksee5UACgkQLPWxlyuTD7LfzgCeNNBHRMuyP8scWJrOfSjFkXiV
fZkAoJoT9lBFwPxlzRRoA5UFjKzDMhUu
=i06N
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
In a konsole or from an icon Blender 2.49b fails to come up in KDE4
(kde4-4.3.85-1.1.i586)
openSuSE 11.3, NVidia factory .run. Seems to be a KDE problem. Need a
KDE BUG report?
Compiled with Python version 2.6.2.
Checking for installed Python... got it!
ERROR: Unable to open Blender window
As root or a user - it comes up and then disappears.
--
73 de Donn Washburn
307 Savoy Street Email:" n5xwb(a)comcast.net "
Sugar Land, TX 77478 LL# 1.281.242.3256
Ham Callsign N5XWB HAMs : " n5xwb(a)arrl.net "
VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg
BMW MOA #: 4146 - Ambassador
" http://counter.li.org " #279316
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Happy New Year to All;
I just tried to get a audio mixer like kmix (Qt3) in openSuSE 11.3 using
"zypper in kmix"
Zypper came back with about 4 or 5 not needed thing that it was going to
remove. Fine! Head on, Do it.
Zypper started and removed about 25 packages and installed kmix.
Execute kmix and
<unknown program name>(829)/: KUniqueApplication: Cannot find the D-Bus
session server: "Did not receive a reply. Possible causes include: the
remote application did not send a reply, the message bus security policy
blocked the reply, the reply timeout expired, or the network connection
was broken."
<unknown program name>(828)/: KUniqueApplication: Pipe closed unexpectedly.
Kmix fails to work!
Is there a list of QT4 <> QT3 programs like kmix to ?
--
73 de Donn Washburn
307 Savoy Street Email:" n5xwb(a)comcast.net "
Sugar Land, TX 77478 LL# 1.281.242.3256
Ham Callsign N5XWB HAMs : " n5xwb(a)arrl.net "
VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg
BMW MOA #: 4146 - Ambassador
" http://counter.li.org " #279316
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
On 30/12/09 20:32, Philipp Thomas wrote:
> On Wed, 30 Dec 2009 14:01:26 -0300, you wrote:
>
>> Yes, and looks like a suitable replacement for XMMS, Im actually using
>> the RPM you just provided, thanks :)
>
> I will have to check in the next days as this sounds promising :)
>
>> Will be great If packman can ship a subpackage qmmp-restricted or
>> similar though.
>
> I'll see what I can do as soon as I'm back from vacation.
I already modified seife's package so it can be link'ed from packman OBS
containing a "restricted" package wrapped in "if packman_bs.."
We now need to
a) package "ProjectM" libraries
b) figure out if "bs2b" is patent encumbered. (legal folks ? )
c) test it, though it compiles with no warnings whatsoever.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
xine-lib 1.1.17 calls for the above library which no longer is part of
xorg-x11-libxcb-devel. There is just libxcb-shape.so.0.0.0 and its
symlinks, also libxcb-shape.la which is used, it's still looking for the
.a even with --enable-shared.
I seem to remember that we were getting rid of .a libraries in openSUSE,
the .a library was still hanging around unowned and unusable after up
upgrades.
I should think the problem is with the source code. Can anyone suggest a
workaround - or may be the xine developers need to be made aware.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
As many of us have vacation, there are currently not
many commits - which is good as it gave me time to fix
up the livecd build :)
So for the first time since 11.2 we have building factory
ISOS at: http://download.opensuse.org/factory/iso/
Happy vacation :)
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
openSuSE 11.2 RC 1
I see "checkinstall" is still broken. Something keeps it from writing
in a directory that exist.
/usr/src/packages/BUILDROOT
--
73 de Donn Washburn
307 Savoy Street Email:" n5xwb(a)comcast.net "
Sugar Land, TX 77478 LL# 1.281.242.3256
Ham Callsign N5XWB HAMs : " n5xwb(a)arrl.net "
VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg
BMW MOA #: 4146 - Ambassador
" http://counter.li.org " #279316
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org