[gentoo-amd64] How do I choose a second window manager?
Hi, A discussion on another list made me realize I'm a little tired of Gnome. It does what I need, mostly, but it feels sort of old and dry. I haven't run KDE in years but I'm hesitant to build it and keep it up to date. I really think I'd like something more minimalistic. I ran fluxbox years ago and liked that it was small and fast but at the time getting to apps was a hand-crafted menu editing task that I'd rather not repeat today. QUESTION: Is there something small, fast but also easy to use in terms of the environment automatically creating menus when apps are added or removed with emerge? From a pure-fun standpoint something 3D might be fun, but I don't need it and expect that my old ATI Radeon X300 card probably isn't up to the task anyway. How do others choose a window manager and what do you value in your window manager that makes you stick with it? Thanks, Mark lightning ~ # eix | grep x11-wm * x11-wm/aewm++ * x11-wm/aewm++-goodies * x11-wm/aewm * x11-wm/afterstep * x11-wm/amiwm * x11-wm/awesome * x11-wm/blackbox * x11-wm/compiz * x11-wm/compiz-fusion * x11-wm/ctwm * x11-wm/dwm * x11-wm/echinus * x11-wm/emerald * x11-wm/enlightenment * x11-wm/evilwm * x11-wm/fluxbox * x11-wm/flwm * x11-wm/fvwm * x11-wm/icewm * x11-wm/ion * x11-wm/jwm * x11-wm/larswm * x11-wm/lwm * x11-wm/matchbox * x11-wm/matchbox-common * x11-wm/matchbox-desktop * x11-wm/matchbox-panel * x11-wm/matchbox-window-manager [I] x11-wm/metacity * x11-wm/openbox * x11-wm/oroborus * x11-wm/oroborus-extras * x11-wm/pekwm * x11-wm/plwm * x11-wm/ratpoison * x11-wm/sawfish * x11-wm/selectwm * x11-wm/stumpwm * x11-wm/treewm [I] x11-wm/twm * x11-wm/vtwm * x11-wm/windowlab * x11-wm/windowmaker * x11-wm/wm2 * x11-wm/wmii * x11-wm/xmonad * x11-wm/xmonad-contrib lightning ~ #
Re: [gentoo-amd64] How do I choose a second window manager?
fluxbox is a nice, lightweight, usable WM :) -- Alex Alexander || wired Gentoo QT KDE Herd Tester http://www.linuxized.com On Wed, Jun 17, 2009 at 15:53, Mark Knechtmarkkne...@gmail.com wrote: Hi, A discussion on another list made me realize I'm a little tired of Gnome. It does what I need, mostly, but it feels sort of old and dry. I haven't run KDE in years but I'm hesitant to build it and keep it up to date. I really think I'd like something more minimalistic. I ran fluxbox years ago and liked that it was small and fast but at the time getting to apps was a hand-crafted menu editing task that I'd rather not repeat today. QUESTION: Is there something small, fast but also easy to use in terms of the environment automatically creating menus when apps are added or removed with emerge? From a pure-fun standpoint something 3D might be fun, but I don't need it and expect that my old ATI Radeon X300 card probably isn't up to the task anyway. How do others choose a window manager and what do you value in your window manager that makes you stick with it? Thanks, Mark lightning ~ # eix | grep x11-wm * x11-wm/aewm++ * x11-wm/aewm++-goodies * x11-wm/aewm * x11-wm/afterstep * x11-wm/amiwm * x11-wm/awesome * x11-wm/blackbox * x11-wm/compiz * x11-wm/compiz-fusion * x11-wm/ctwm * x11-wm/dwm * x11-wm/echinus * x11-wm/emerald * x11-wm/enlightenment * x11-wm/evilwm * x11-wm/fluxbox * x11-wm/flwm * x11-wm/fvwm * x11-wm/icewm * x11-wm/ion * x11-wm/jwm * x11-wm/larswm * x11-wm/lwm * x11-wm/matchbox * x11-wm/matchbox-common * x11-wm/matchbox-desktop * x11-wm/matchbox-panel * x11-wm/matchbox-window-manager [I] x11-wm/metacity * x11-wm/openbox * x11-wm/oroborus * x11-wm/oroborus-extras * x11-wm/pekwm * x11-wm/plwm * x11-wm/ratpoison * x11-wm/sawfish * x11-wm/selectwm * x11-wm/stumpwm * x11-wm/treewm [I] x11-wm/twm * x11-wm/vtwm * x11-wm/windowlab * x11-wm/windowmaker * x11-wm/wm2 * x11-wm/wmii * x11-wm/xmonad * x11-wm/xmonad-contrib lightning ~ #
Re: [gentoo-amd64] How do I choose a second window manager?
On Wed, Jun 17, 2009 at 3:03 PM, Alex Alexander alex.alexan...@gmail.com wrote: fluxbox is a nice, lightweight, usable WM :) I have used IceWM (http://www.icewm.org/) for years on an old P2 233MHz with 64Mb RAM. But you had to edit the menu by editing a text file. Ubuntu has a lightweight version (Xubuntu) which uses XFCE (http://www.xfce.org/). You could download a xubuntu iso image and run it from the live-cd to experience it's features. XFCE seems to have a more active development (more recent releases) than IceWM. That's also true for the e-builds: http://www.gentoo-portage.com/xfce-base/xfce4/ChangeLog#ptabs HTH, Martin P.S. anyone noticed that this time I didn't forget to send only plain text instead of all the HTML stuff? :-D -- Alex Alexander || wired Gentoo QT KDE Herd Tester http://www.linuxized.com
Re: [gentoo-amd64] How do I choose a second window manager?
On Wed, Jun 17, 2009 at 3:10 PM, Mark Knechtmarkkne...@gmail.com wrote: Yep. And so small I built it by the time your response came back and am answering your message from within it. Granted, black screen and the menus don't see any of the apps I have installed, so that's the same old problem. Isn't there some app for automatically picking up apps on putting the menu together auto-magically? Cheers, Mark The Xfce 4 Appfinder is part of the Xfce 4 Desktop Environment and features application search on the whole system. It searches for .desktop files based on the freedesktop spec and makes an index of the found apps. Source: xfce website: http://www.xfce.org/documentation/4.2/manuals/xfce4-appfinder Does Gentoo use these .desktop files?
[gentoo-amd64] Re: How do I choose a second window manager?
Martin Herrman mar...@herrman.nl posted 40bb8d3b0906170618g152b5f8fxc79889f0d6213...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 15:18:24 +0200: The Xfce 4 Appfinder is part of the Xfce 4 Desktop Environment and features application search on the whole system. It searches for .desktop files based on the freedesktop spec and makes an index of the found apps. Source: xfce website: http://www.xfce.org/documentation/4.2/manuals/xfce4-appfinder Does Gentoo use these .desktop files? In general, yes, as it's a freedesktop.org standard now and both KDE and GNOME use them too. However, whether individual (non-main-DE) apps packages include them would depend on either upstream (if it ships, so will Gentoo in most cases) or the the initiative of the individual Gentoo package maintainer, if upstream doesn't ship one. On the title question, I've never used it, but based on what others have said and the originally requested features (including an auto-managed menu), I too would recommend XFCE. It seems to be /the/ middle ground between a full feature DE and a bare-bones WM, and gets very high reviews in general. If I ever decide KDE's not for me any more, or perhaps for my netbook when I get around to putting Gentoo on it, if I don't like KDE's performance, I've always thought I'd try XFCE first. But on my main machine, at least kde3 has been great. I can't say the same for kde4 (yet?), for a couple reasons. First, one of the big kde4 features is 3D eye candy... that my aging Radeon 9200 can't handle at the 1920x2400 desktop size I run (it maxes at 2048 each, X and Y), and without that, there really isn't enough better (and a lot changed enough I'm not comfortable with it) to upgrade from kde3. Second, I've so deeply customized kde3 to my own needs and style, and kde4 is so much changed, that it's simply different enough that even with full 3D features, it'd take me awhile to get kde4 setup similarly effectively/ comfortably. So, I have both kde3/4 merged, and occasionally run 4 and mess around some, but for actually doing anything productive, it's kde3 (or the text console). Sometime later this year I plan to upgrade to, probably, one of the later r500 based Radeons (which run thru the x1950 models), and meanwhile, kde-4.3.0 and likely 4.3.1 will be out, and we'll see how kde4 does then. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-amd64] Hurray! Radeon KMS in 2.6.31
As I've mentioned a couple times recently, I run direct Linus kernel git. Previously I've waited until rc2 or so before trying the new development kernel, but I got bored and decided to try following the kernel even in the merge window this time. Sometime in the last 24 hours or so, Linus merged the Radeon KMS (kernel mode setting) code! I've been looking forward to this for a couple versions now, so am glad it's finally here! Presently, it's only thru the Radeon r5xx chip series, so thru the model x1950 cards. They'll add the newer r6xx/r7xx chips (beyond x1950 and the hd* cards) later. Of course I'm not actually running kms yet, as my X userspace isn't new enough (I don't think, AFAIK the xorg-server-1.6.1.901-r3 that I'm running should support it, but the xf86-video-ati-6.12.2 doesn't yet, I'd need the - live git version for that, and would probably need to match it with the live-git xorg-server- as well), so I've not enabled the kernel's radeon-kms-by-default option, which appears under the staging drivers for the moment. But it's in the kernel mainline now, and I'm running that kernel (2.6.30-6553-g65795ef) with no general observed issues ATM. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-amd64] How do I choose a second window manager?
Am Wed, 17 Jun 2009 06:10:42 -0700 schrieb Mark Knecht markkne...@gmail.com: On Wed, Jun 17, 2009 at 6:03 AM, Alex Alexanderalex.alexan...@gmail.com wrote: fluxbox is a nice, lightweight, usable WM :) -- Alex Alexander || wired Gentoo QT KDE Herd Tester http://www.linuxized.com Yep. And so small I built it by the time your response came back and am answering your message from within it. Granted, black screen and the menus don't see any of the apps I have installed, so that's the same old problem. Isn't there some app for automatically picking up apps on putting the menu together auto-magically? I used to use fluxbox, though switched to awesome in the meantime. The same thing irritated me, too. There is the fluxbox-generate_menu script, but it produces a somewhat scarce menu. So I used fbpanel: mar...@marcec ~ % eix fbpanel [I] x11-misc/fbpanel Available versions: 4.12 Installed versions: 4.12(11:50:28 01.04.2009) Homepage:http://fbpanel.sourceforge.net/ Description: light-weight X11 desktop panel That comes with a (not 100%, I believe science packages, e.g. gEDA, don't show up) complete menu. Cheers, Mark HTH -- Marc Joliet -- Lt. Frank Drebin: It's true what they say: cops and women don't mix. Like eating a spoonful of Drāno; sure, it'll clean you out, but it'll leave you hollow inside. signature.asc Description: PGP signature
Re: [gentoo-amd64] How do I choose a second window manager?
How do others choose a window manager and what do you value in your window manager that makes you stick with it? I value most what most modern WM's do not implement - large viewports on virtual desktops. Those WM's with distinct workspaces are such a regression for me ...
Re: [gentoo-amd64] Re: How do I choose a second window manager?
On Wed, Jun 17, 2009 at 6:43 AM, Duncan1i5t5.dun...@cox.net wrote: Martin Herrman mar...@herrman.nl posted 40bb8d3b0906170618g152b5f8fxc79889f0d6213...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 15:18:24 +0200: The Xfce 4 Appfinder is part of the Xfce 4 Desktop Environment and features application search on the whole system. It searches for .desktop files based on the freedesktop spec and makes an index of the found apps. Source: xfce website: http://www.xfce.org/documentation/4.2/manuals/xfce4-appfinder Does Gentoo use these .desktop files? In general, yes, as it's a freedesktop.org standard now and both KDE and GNOME use them too. However, whether individual (non-main-DE) apps packages include them would depend on either upstream (if it ships, so will Gentoo in most cases) or the the initiative of the individual Gentoo package maintainer, if upstream doesn't ship one. On the title question, I've never used it, but based on what others have said and the originally requested features (including an auto-managed menu), I too would recommend XFCE. It seems to be /the/ middle ground between a full feature DE and a bare-bones WM, and gets very high reviews in general. If I ever decide KDE's not for me any more, or perhaps for my netbook when I get around to putting Gentoo on it, if I don't like KDE's performance, I've always thought I'd try XFCE first. But on my main machine, at least kde3 has been great. I can't say the same for kde4 (yet?), for a couple reasons. First, one of the big kde4 features is 3D eye candy... that my aging Radeon 9200 can't handle at the 1920x2400 desktop size I run (it maxes at 2048 each, X and Y), and without that, there really isn't enough better (and a lot changed enough I'm not comfortable with it) to upgrade from kde3. Second, I've so deeply customized kde3 to my own needs and style, and kde4 is so much changed, that it's simply different enough that even with full 3D features, it'd take me awhile to get kde4 setup similarly effectively/ comfortably. So, I have both kde3/4 merged, and occasionally run 4 and mess around some, but for actually doing anything productive, it's kde3 (or the text console). Sometime later this year I plan to upgrade to, probably, one of the later r500 based Radeons (which run thru the x1950 models), and meanwhile, kde-4.3.0 and likely 4.3.1 will be out, and we'll see how kde4 does then. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman I suspect that XFCE might be a good one to look at. Thanks. Any thoughts from folks about fvwm? thanks to Marc for the pointer to fbpanel. I'll certainly take a look at that. cheers, Mark
Re: [gentoo-amd64] Re: How do I choose a second window manager?
On Wed, Jun 17, 2009 at 8:39 AM, Dmitri Pogosyanpogos...@phys.ualberta.ca wrote: I used XFCE for a year, having mostly left kde-3.5 unused, but recently since the update to 3.5.10 came out, and was modular, have updated to just barebone kdebase-meta. You know - it feels faster than XFCE, and weights in kdebase + couple apps I need, not much more. I too would recommend XFCE. It seems to be /the/ middle ground between a full feature DE and a bare-bones WM, and gets very high reviews in general. If I ever decide KDE's not for me any more, or perhaps for my netbook when I get around to putting Gentoo on it, if I don't like KDE's performance, I've always thought I'd try XFCE first. But on my main machine, at least kde3 has been great. -- Dmitri Pogosyan Department of Physics Associate Professor University of Alberta tel 1-780-492-2150 11322 - 89 Avenue fax 1-780-492-0714 Edmonton, AB, T6G 2G7, CANADA Good input. QUESTION: I've been somewhat unhappy over the last year with Gentoo package maintainers doing little updates to gnome files which seems to drive more and more little updates. Granted, I could mask things, etc., but I've found it frustrating. I've worried with KDE that it's so big I'll find myself updating files pretty much all the time. Is this warranted or just me worrying? Cheers, Mark
Re: [gentoo-amd64] Hurray! Radeon KMS in 2.6.31
On Wed, Jun 17, 2009 at 7:15 AM, Duncan1i5t5.dun...@cox.net wrote: As I've mentioned a couple times recently, I run direct Linus kernel git. Previously I've waited until rc2 or so before trying the new development kernel, but I got bored and decided to try following the kernel even in the merge window this time. Sometime in the last 24 hours or so, Linus merged the Radeon KMS (kernel mode setting) code! I've been looking forward to this for a couple versions now, so am glad it's finally here! Presently, it's only thru the Radeon r5xx chip series, so thru the model x1950 cards. They'll add the newer r6xx/r7xx chips (beyond x1950 and the hd* cards) later. Of course I'm not actually running kms yet, as my X userspace isn't new enough (I don't think, AFAIK the xorg-server-1.6.1.901-r3 that I'm running should support it, but the xf86-video-ati-6.12.2 doesn't yet, I'd need the - live git version for that, and would probably need to match it with the live-git xorg-server- as well), so I've not enabled the kernel's radeon-kms-by-default option, which appears under the staging drivers for the moment. But it's in the kernel mainline now, and I'm running that kernel (2.6.30-6553-g65795ef) with no general observed issues ATM. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman So what would KMS do for me when I finally have access to it? Thanks, Mark
Re: [gentoo-amd64] How do I choose a second window manager?
On Wed, Jun 17, 2009 at 7:53 AM, Mark Knechtmarkkne...@gmail.com wrote: A discussion on another list made me realize I'm a little tired of Gnome. It does what I need, mostly, but it feels sort of old and dry. I haven't run KDE in years but I'm hesitant to build it and keep it up to date. I really think I'd like something more minimalistic. I ran fluxbox years ago and liked that it was small and fast but at the time getting to apps was a hand-crafted menu editing task that I'd rather not repeat today. QUESTION: Is there something small, fast but also easy to use in terms of the environment automatically creating menus when apps are added or removed with emerge? From a pure-fun standpoint something 3D might be fun, but I don't need it and expect that my old ATI Radeon X300 card probably isn't up to the task anyway. How do others choose a window manager and what do you value in your window manager that makes you stick with it? I use KDE4 and keep XFCE as a backup. I use KDM as login manager and it easily lets me choose which one I want. I use only XFCE on my laptop because compiling gnome or KDE is just too much work for it. I could easily use XFCE (or Gnome) as primary desktop environment and be happy, but I'm just used to KDE.
Re: [gentoo-amd64] How do I choose a second window manager?
On Wed, Jun 17, 2009 at 8:50 AM, Paul Hartmanpaul.hartman+gen...@gmail.com wrote: On Wed, Jun 17, 2009 at 7:53 AM, Mark Knechtmarkkne...@gmail.com wrote: A discussion on another list made me realize I'm a little tired of Gnome. It does what I need, mostly, but it feels sort of old and dry. I haven't run KDE in years but I'm hesitant to build it and keep it up to date. I really think I'd like something more minimalistic. I ran fluxbox years ago and liked that it was small and fast but at the time getting to apps was a hand-crafted menu editing task that I'd rather not repeat today. QUESTION: Is there something small, fast but also easy to use in terms of the environment automatically creating menus when apps are added or removed with emerge? From a pure-fun standpoint something 3D might be fun, but I don't need it and expect that my old ATI Radeon X300 card probably isn't up to the task anyway. How do others choose a window manager and what do you value in your window manager that makes you stick with it? I use KDE4 and keep XFCE as a backup. I use KDM as login manager and it easily lets me choose which one I want. I use only XFCE on my laptop because compiling gnome or KDE is just too much work for it. I could easily use XFCE (or Gnome) as primary desktop environment and be happy, but I'm just used to KDE. Hi Paul, I do a lot of audio work using apps and a kernel (rt-sources) from the pro-audio overlay. Jack, Ardour, etc. Really low latency and NO long window manager delays are more important for me that they probably are for others. I ran KDE years ago and it just didn't work very well, but in those days even Gnome wasn't very good so I used fluxbox which was great. Well, today Gnome is fine, and maybe KDE would be also. Historically it just wasn't a good fit more me in the past. I guess the other thing that I'm interested in is getting beyond this flat/old Gnome is sort of like Windows sensation that I am feeling right now so to warrant the effort to actually use something I suppose I am really looking for something with a really different feel but it still really works in terms of getting jobs done. Something that makes me feel good about even firing up the desktop. Cheers, Mark
Re: [gentoo-amd64] How do I choose a second window manager?
Mark Knecht, mused, then expounded: On Wed, Jun 17, 2009 at 8:50 AM, Paul Hartmanpaul.hartman+gen...@gmail.com wrote: On Wed, Jun 17, 2009 at 7:53 AM, Mark Knechtmarkkne...@gmail.com wrote: Â QUESTION: Is there something small, fast but also easy to use in terms of the environment automatically creating menus when apps are added or removed with emerge? Â How do others choose a window manager and what do you value in your window manager that makes you stick with it? Hi Paul, I guess the other thing that I'm interested in is getting beyond this flat/old Gnome is sort of like Windows sensation that I am feeling right now so to warrant the effort to actually use something I suppose I am really looking for something with a really different feel but it still really works in terms of getting jobs done. Something that makes me feel good about even firing up the desktop. Cheers, Mark Enlightenment 0.16 - either you like it so that even after switching to others, you always come back. Or you just don't get along with it. The only time I've gone for a lighter weight WM has been on a netbook where LXDE is run. Bob -- -
Re: [gentoo-amd64] Re: How do I choose a second window manager?
Mark Knecht markkne...@gmail.com writes:
QUESTION: I've been somewhat unhappy over the last year with Gentoo
package maintainers doing little updates to gnome files which seems to
drive more and more little updates.
What do you mean, exactly? I upgrade weekly, and haven't really noticed
this, or noticed it to be a problem.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgp6aAsbOQZ27.pgp
Description: PGP signature
Re: [gentoo-amd64] How do I choose a second window manager?
On Wed, Jun 17, 2009 at 11:02 AM, Mark Knechtmarkkne...@gmail.com wrote: Hi Paul, I do a lot of audio work using apps and a kernel (rt-sources) from the pro-audio overlay. Jack, Ardour, etc. Really low latency and NO long window manager delays are more important for me that they probably are for others. I ran KDE years ago and it just didn't work very well, but in those days even Gnome wasn't very good so I used fluxbox which was great. Well, today Gnome is fine, and maybe KDE would be also. Historically it just wasn't a good fit more me in the past. I guess the other thing that I'm interested in is getting beyond this flat/old Gnome is sort of like Windows sensation that I am feeling right now so to warrant the effort to actually use something I suppose I am really looking for something with a really different feel but it still really works in terms of getting jobs done. Something that makes me feel good about even firing up the desktop. Well, if you want something different then KDE4 is definitely different... for better or for worse :) XFCE is more similar to Gnome in that both of them remind me of a Mac OS desktop. (KDE4 is more like Vista/Win7) However, XFCE is a fraction of the size of KDE or Gnome, which is nice. Being able to compile the whole thing in just a few minutes is a good change of pace. Check out http://xwinman.org/ for many other options.
Re: [gentoo-amd64] How do I choose a second window manager?
QUESTION: Is there something small, fast but also easy to use in terms of the environment automatically creating menus when apps are added or removed with emerge? Openbox is my choice for a window manager. Openbox is fast and small and that well suits my minimalistic approach. Openbox also provides virtual desktops that are, IMO, indispensable to a graphical interface. With Openbox there is no automatic method to create menus but the configuration files are very easy to manually edit. Once a basic menu structure is established, a simple cut and paste operation can be used to quickly update. There is also a configuration tool available for Openbox, but since I have never used it I cannot comment about it. Frank Peters
Re: [gentoo-amd64] Re: How do I choose a second window manager?
I was never fond of split ebuilds, because I found you end up installing almost everything anyway but managing them becomes much more cumbersome. Bad example is X - I do not have qualification anyway to decide that I need this library but not that one, and it seems that every single library comes in it own ebuild, so you start to wonder why not compile each C program individually. Saying that, I found KDE 3.5.10 split extremely well thought through and really useful. It is organzied in well defined (and not too numerous) meta blocks which contain pieces of service packages (like kioslaves) that are relevant to this block, kdebase-meta is fully functional minimalist installation, and extra apps that you may need are very intuitive to find. So kudos to developers on that. Good input. QUESTION: I've been somewhat unhappy over the last year with Gentoo package maintainers doing little updates to gnome files which seems to drive more and more little updates. Granted, I could mask things, etc., but I've found it frustrating. I've worried with KDE that it's so big I'll find myself updating files pretty much all the time. Is this warranted or just me worrying? Cheers, Mark -- Dmitri PogosyanDepartment of Physics Associate ProfessorUniversity of Alberta tel 1-780-492-2150 11322 - 89 Avenue fax 1-780-492-0714 Edmonton, AB, T6G 2G7, CANADA
[gentoo-amd64] How do I switch to a window manager?
Can somebody answer a question, related to the favorite WM question, how do I change to an alternative window manager? I normally run xdm and update my .xinitrc or .xsession file to do this but I feel that there should be a better way. How do you do it? Thanks, -- Steve Herberher...@thing.comwork: 206-221-7262 Software Engineer, UW Medicine, IT Services home: 425-454-2399
Re: [gentoo-amd64] How do I switch to a window manager?
Steve Herber, mused, then expounded: Can somebody answer a question, related to the favorite WM question, how do I change to an alternative window manager? Edit /etc/rc.conf and /etc/conf.d/xdm Bob -
Re: [gentoo-amd64] How do I switch to a window manager?
On Wed, Jun 17, 2009 at 9:39 AM, Steve Herberher...@thing.com wrote: Can somebody answer a question, related to the favorite WM question, how do I change to an alternative window manager? I normally run xdm and update my .xinitrc or .xsession file to do this but I feel that there should be a better way. How do you do it? Thanks, -- Steve Herber her...@thing.com work: 206-221-7262 Software Engineer, UW Medicine, IT Services home: 425-454-2399 I use gdm as a log in manager. On the bottom of the login screen there is a pull down that allows me to choose which one I want to run and whether to make it default or to only use it for this session. Hope this helps, Mark
[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
Mark Knecht markkne...@gmail.com posted 5bdc1c8b0906170847u241d3f5fg34cc48d6e1a5a...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 08:47:57 -0700: So what would KMS do for me when I finally have access to it? KMS, kernel mode setting, finally unifies the mode (resolution) setting between X and the text console framebuffer. This has always been a very hairy and delicate area, with all sorts of potential and real bugs due to what's essentially two entirely separate sets of code handling the display. Often, the bugs showed up as being unable to get a text console back once X took over, or in full machine crashes. But there's more to it than simply avoiding that. Among other things, for those who consider boot to mean starting X and getting to a graphical login (or auto-login all the way to the desktop), it'll mean avoiding the disconcerting blinks and moments of blank-screen as X starts, as X will (normally) continue to use the same mode the text framebuffer was using. For those that like staring at rather uninformative picture during the boot process, rather than seeing all those text messages go by, that will work better and be smoother as well. Also, the process will be much faster, as currently, the kernel runs its detection at boot, then X runs its detection when it starts, and now those will be combined into only a single detection run. Switching between a text VT and the X VT (or more than one X VT, with fast-user- switching) will be much faster and less prone to lockups, as well. Another big feature KMS brings is that letting the kernel handle all that code will mean that the X userspace code doesn't need root privs any more, and can be started as a normal user. For /decades/ (since before Linux even came to be) the fact that all that hard-to-audit X code runs as root, with X generally the biggest application by far to run as root, has made the computer security types extremely nervous, thinking about all the potential ways all that X code running as root might be exploited to get root privs. Now X will be able to run as an ordinary user program, or as a non-root system level xorg user or the like, just as most other system level services do. That's going to make a *LOT* of security folks MUCH happier! =:^) Yet another KMS feature will be that finally, when there's a system crash within X, the kernel will be able to spit the kernel panic to the screen, where people can grab the info and report it, something that has only worked from a text console before, because X controlled the display when it was showing and the kernel, particularly an already panicking kernel, couldn't simply grab it and print the error like it could from text mode. (FWIW, these sorts of problems can't be logged to local disk either, because by the time the kernel knows there's a problem, it dares not write anything else to disk because it can't be sure it's in a sane enough state to know where it's writing any more. It can write to a network port if network logging is enabled, or to the screen, but not to disk, lest it overwrite something valuable because it's screwed up enough it doesn't know where on the disk it's writing.) In a way, this brings the infamous BSOD to Linux -- Linux can spit out that final crash message just like Windows can, now -- but of course we think we can do it better than Windows does. But one does hope that whatever they come up with for this doesn't in time become as famous as the BSOD on Windows! Finally, the X graphics drivers, including the 3D/DRM hardware level drivers, are going to become much simpler. Basically, after the change is complete, either the X hardware level drivers will be a thin wrapper around the interface the kernel exposes, or they'll not exist at all, with X sending everything to the kernel over a generic interface, say OpenGL, at least for newer hardware, that really doesn't have a dedicated 2D hardware layer at all, only emulation running on the 3D layer. In either case, however, X will be smaller and rather less complicated, while the much faster updating kernel handles the hardware. Among other things, this will likely mean much faster support for new graphics cards, etc, again, because all the code is in one place now, not two very different code sets sharing and fighting with each other for control, that must be coordinated between themselves as well as updated for the new hardware. Thus, in general, it'll be a much smoother, potentially much faster, and much safer, experience for the user. OTOH, getting from here to there will involve some challenges. The Intel graphics folks have been bearing the brunt of it, leading the pack, with quite some bleeding going on as well, as the various levels temporarily fell out of sync with each other, with some hardware supported best using one combination of kernel, x-driver, drm modules, and xorg-server, while other hardware was supported best
Re: [gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
On Wed, Jun 17, 2009 at 10:24 AM, Duncan1i5t5.dun...@cox.net wrote: Mark Knecht markkne...@gmail.com posted 5bdc1c8b0906170847u241d3f5fg34cc48d6e1a5a...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 08:47:57 -0700: So what would KMS do for me when I finally have access to it? KMS, kernel mode setting, finally unifies the mode (resolution) setting between X and the text console framebuffer. This has always been a very hairy and delicate area, with all sorts of potential and real bugs due to what's essentially two entirely separate sets of code handling the display. Often, the bugs showed up as being unable to get a text console back once X took over, or in full machine crashes. But there's more to it than simply avoiding that. Among other things, for those who consider boot to mean starting X and getting to a graphical login (or auto-login all the way to the desktop), it'll mean avoiding the disconcerting blinks and moments of blank-screen as X starts, as X will (normally) continue to use the same mode the text framebuffer was using. For those that like staring at rather uninformative picture during the boot process, rather than seeing all those text messages go by, that will work better and be smoother as well. Also, the process will be much faster, as currently, the kernel runs its detection at boot, then X runs its detection when it starts, and now those will be combined into only a single detection run. Switching between a text VT and the X VT (or more than one X VT, with fast-user- switching) will be much faster and less prone to lockups, as well. Another big feature KMS brings is that letting the kernel handle all that code will mean that the X userspace code doesn't need root privs any more, and can be started as a normal user. For /decades/ (since before Linux even came to be) the fact that all that hard-to-audit X code runs as root, with X generally the biggest application by far to run as root, has made the computer security types extremely nervous, thinking about all the potential ways all that X code running as root might be exploited to get root privs. Now X will be able to run as an ordinary user program, or as a non-root system level xorg user or the like, just as most other system level services do. That's going to make a *LOT* of security folks MUCH happier! =:^) Yet another KMS feature will be that finally, when there's a system crash within X, the kernel will be able to spit the kernel panic to the screen, where people can grab the info and report it, something that has only worked from a text console before, because X controlled the display when it was showing and the kernel, particularly an already panicking kernel, couldn't simply grab it and print the error like it could from text mode. (FWIW, these sorts of problems can't be logged to local disk either, because by the time the kernel knows there's a problem, it dares not write anything else to disk because it can't be sure it's in a sane enough state to know where it's writing any more. It can write to a network port if network logging is enabled, or to the screen, but not to disk, lest it overwrite something valuable because it's screwed up enough it doesn't know where on the disk it's writing.) In a way, this brings the infamous BSOD to Linux -- Linux can spit out that final crash message just like Windows can, now -- but of course we think we can do it better than Windows does. But one does hope that whatever they come up with for this doesn't in time become as famous as the BSOD on Windows! Finally, the X graphics drivers, including the 3D/DRM hardware level drivers, are going to become much simpler. Basically, after the change is complete, either the X hardware level drivers will be a thin wrapper around the interface the kernel exposes, or they'll not exist at all, with X sending everything to the kernel over a generic interface, say OpenGL, at least for newer hardware, that really doesn't have a dedicated 2D hardware layer at all, only emulation running on the 3D layer. In either case, however, X will be smaller and rather less complicated, while the much faster updating kernel handles the hardware. Among other things, this will likely mean much faster support for new graphics cards, etc, again, because all the code is in one place now, not two very different code sets sharing and fighting with each other for control, that must be coordinated between themselves as well as updated for the new hardware. Thus, in general, it'll be a much smoother, potentially much faster, and much safer, experience for the user. OTOH, getting from here to there will involve some challenges. The Intel graphics folks have been bearing the brunt of it, leading the pack, with quite some bleeding going on as well, as the various levels temporarily fell out of sync with each other, with some hardware supported best using one combination of kernel,
[gentoo-amd64] Re: How do I choose a second window manager?
Dmitri Pogosyan pogos...@phys.ualberta.ca posted 200906171636.n5hgarp03...@webmail.phys.ualberta.ca, excerpted below, on Wed, 17 Jun 2009 10:36:27 -0600: I was never fond of split ebuilds, because I found you end up installing almost everything anyway but managing them becomes much more cumbersome. Bad example is X - I do not have qualification anyway to decide that I need this library but not that one, and it seems that every single library comes in it own ebuild, so you start to wonder why not compile each C program individually. FWIW, with X, you should no longer need the xorg-x11 meta-package, and without it, pretty much everything you need is now a dependency either of xorg-server or of the various other X packages you may install that need it. Among other things, eliminating the xorg-x11 metapackage will likely allow depclean to uninstall quite a number of unnecessary (for most people, they help with exotic fonts for Uzbekistan, etc.) font packages and the like, some of which are unfree, something at least some of us are concerned about. Then you don't have to worry about X any more, as only what you need is pulled in as dependencies of whatever. Unless of course you want some exotic font or something. Then you just emerge that to get it added to world on its own, and don't worry about it any more, either. So it basically ends up much as you were saying KDE does (and I agree). Just as kdebase-meta pulls in the basics there, xorg-server (well, once you set the INPUT_DEVICES and VIDEO_CARDS variables as appropriate) pulls in the basics for X. But just as with KDE, it wasn't always that way. It took them several version generations worth of practice to get all the metas and dependencies setup correctly. Before that, you'd often have trouble with missing dependencies unless you merged the overall meta-package (kde-meta or xorg-x11), because the dependencies weren't all worked out properly yet and individual packages were often missing one or more of them. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
On 06/17/2009 08:35 PM, Mark Knecht wrote: Good stuff. So guessing about the path: 1) Kernel get KMS. 2) Xorg-X11 develops and tests for awhile. (probably on-going now?) Yup, it's working already because Intel graphics chips already had KMS for a while now. It's already in Ubuntu and Fedora (though not enabled by default, I think.) 3) Gentoo devs and bleeding edge users play with it for awhile. 4) Shows up in portage under ~amd64 (Is that the same as ~arch for AMD64?) ~arch means the same regardless of architecture ;) It's ~x86 for IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc. 5) More bleeding edge users play with it 6) Becomes stable 7) I get it. What's that? About 1-2 years or something? Probably sooner. New X.Org releases will hit stable portage much sooner then it took for 1.5 to arrive since the jump from 1.3 to 1.5 was much harder than the future jump from 1.5 to 1.6. None the less, sounds like quite a nice improvement. I've had LOTS of times where going back and forth between console and X hasn't been perfect, and I certainly don't like the annoying blinks, etc. Switching to a VT instantly (and it's really *instant*; it's like switching to another virtual desktop) is the most important feature for me. Running X as user comes next. The boot thingy isn't important at all to me. Unfortunately, it will be a whole while for me to get it since I'm on a Radeon HD4870 which is not supported by any open source drivers at all right now.
[gentoo-amd64] Re: How do I choose a second window manager?
Paul Hartman paul.hartman+gen...@gmail.com posted 58965d8a0906170914l4ebca650uba703a2a6b450...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 11:14:50 -0500: Well, if you want something different then KDE4 is definitely different... for better or for worse :) Agreed, but if he wants low latency, he'll probably want to be sure to turn off all the fancy 3D window effects, transparency and the like, and with that goes much of the reason for using KDE4. =:^( If he has a fast graphics card and a relatively low resolution screen, he may be able to get away with very limited effects, but if I'm right, even that might be a bit too unpredictable in terms of latency. Meanwhile, Mark, you do have the kernel set for a 1000 Hz clock rate, right? And you have preemptive desktop turned on, and high resolution timers, right? (These are under Processor type and features.) You may also wish to experiment with Group CPU Scheduler (under General setup), if you regularly run background tasks as other users and you want to be sure your audio user gets his share of CPU. With that on you can then tweak the /sys/kernel/uids/idnum/cpu_share numbers, keeping in mind that the default is 1024 while the root default is 2048, and that the idnum dirs will come and go as users do. I don't do your sort of audio, and run the more moderate voluntary preemption and 300 Hz clock (with tickless also on), but combined with setting PORTAGE_NICENESS=19 in make.conf, I can run all sorts of emerge jobs, CPU loads in the hundreds if I want as long as don't run too far into swap, and still keep a relatively responsive desktop, and if I had full preemption and 1000 Hz, I think I could almost do your style of recording even while running emerges! (Oh, I also have PORTAGE_TMPDIR pointed at a tmpfs, thus keeping unnecessary I/O to a minimum. That makes a difference to responsiveness while merging too, as does having the memory to keep it out of swap while doing so.) Of course, it may be that you simply don't run enough background tasks as other users to make any difference with the group scheduling stuff, and that was only added in 2.6.27 or some such, so if you're running an old kernel you won't have the group scheduling at all. IOW, YMMV, but it's worth looking at. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
On Wed, Jun 17, 2009 at 11:02 AM, Nikos Chantziaras rea...@arcor.de wrote: On 06/17/2009 08:35 PM, Mark Knecht wrote: Good stuff. So guessing about the path: 1) Kernel get KMS. 2) Xorg-X11 develops and tests for awhile. (probably on-going now?) Yup, it's working already because Intel graphics chips already had KMS for a while now. It's already in Ubuntu and Fedora (though not enabled by default, I think.) Just as a note - the Radeon KMS uses a different implementation path than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory management, while Radeon (and Nouveau, and other upcoming) use the new TTM (which is also new for .31) - I don't *think* this will affect how X interfaces with the kernel driver, but, since TTM is newer than GEM (GEM/Intel KMS happened in .29), it might still be a little bit before the wrinkles are worked out. As far as the X server interfacing with the new kernel driver, I *believe* that pretty much all the action behind the scenes happens in the X driver itself, with the X server being pretty much unaware of the change (please feel free to correct me if I'm wrong), so, just because the Intel driver has already been utilizing the KMS kernel interface for a little while, doesn't necessarily mean that it will make the Radeon X driver transition any smoother/better/shorter. 3) Gentoo devs and bleeding edge users play with it for awhile. 4) Shows up in portage under ~amd64 (Is that the same as ~arch for AMD64?) ~arch means the same regardless of architecture ;) It's ~x86 for IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc. 5) More bleeding edge users play with it 6) Becomes stable 7) I get it. What's that? About 1-2 years or something? Probably sooner. New X.Org releases will hit stable portage much sooner then it took for 1.5 to arrive since the jump from 1.3 to 1.5 was much harder than the future jump from 1.5 to 1.6. Dunno - X server 1.6 has been out for quite a while (several months - X server 1.7 is due out in just about 1.5 months at this point), and it just very recently hit the portage ~ tree (not that I'm complaining Devs - I understand that there were issues that would've bit lots of users), so it might be a while before you see Radeon KMS support in the fully stable portage tree - don't hold your breath quite yet. ;) Of course, if your system isn't mission-critical, you could always install the - versions, or at least the ~ versions when they hit, and help move along the debugging/stabilization process, so that they hit the stable tree faster... ;) None the less, sounds like quite a nice improvement. I've had LOTS of times where going back and forth between console and X hasn't been perfect, and I certainly don't like the annoying blinks, etc. Switching to a VT instantly (and it's really *instant*; it's like switching to another virtual desktop) is the most important feature for me. Running X as user comes next. The boot thingy isn't important at all to me. Unfortunately, it will be a whole while for me to get it since I'm on a Radeon HD4870 which is not supported by any open source drivers at all right now. Having run the Intel KMS kernel/fbcon/X driver for a little while now, I can say that 2 things *really* stand out to me (at least from my usage model): 1. Native framebuffer console resolution on my 1680x1050 widescreen LCD - no more 1280x1024 stretched! (Actually not sure if this is directly due to the kernel updates for Intel/KMS, or just happened to happen at the same time, but still - Yay!) 2. Perfectly fast X/virtual console switching - I mean - Wow! I still, from time to time, just sit there switching between the two a couple times just to watch the speed and smoothness - it's amazing... -James
Re: [gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
James Ausmus wrote: On Wed, Jun 17, 2009 at 11:02 AM, Nikos Chantziaras rea...@arcor.de mailto:rea...@arcor.de wrote: On 06/17/2009 08:35 PM, Mark Knecht wrote: Good stuff. So guessing about the path: 1) Kernel get KMS. 2) Xorg-X11 develops and tests for awhile. (probably on-going now?) Yup, it's working already because Intel graphics chips already had KMS for a while now. It's already in Ubuntu and Fedora (though not enabled by default, I think.) Just as a note - the Radeon KMS uses a different implementation path than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory management, while Radeon (and Nouveau, and other upcoming) use the new TTM (which is also new for .31) - I don't *think* this will affect how X interfaces with the kernel driver, but, since TTM is newer than GEM (GEM/Intel KMS happened in .29), it might still be a little bit before the wrinkles are worked out. TTM is actually older than GEM, but the Intel guys didn't like TTM and invented GEM. But GEM is more of an interface than an implementation. Intel has their own implementation of the GEM interface, and Radeon and Nouveau will probably share the TTM-based GEM implementation that has entered the kernel now. Sebastian
[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
On 06/17/2009 09:48 PM, Sebastian Redl wrote: James Ausmus wrote: On Wed, Jun 17, 2009 at 11:02 AM, Nikos Chantziarasrea...@arcor.de mailto:rea...@arcor.de wrote: Just as a note - the Radeon KMS uses a different implementation path than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory management, while Radeon (and Nouveau, and other upcoming) use the new TTM (which is also new for .31) - I don't *think* this will affect how X interfaces with the kernel driver, but, since TTM is newer than GEM (GEM/Intel KMS happened in .29), it might still be a little bit before the wrinkles are worked out. TTM is actually older than GEM, but the Intel guys didn't like TTM and invented GEM. But GEM is more of an interface than an implementation. Intel has their own implementation of the GEM interface, and Radeon and Nouveau will probably share the TTM-based GEM implementation that has entered the kernel now. GEM is newer and more suitable for non high-performance chips, like integrated graphics chips from Intel. High-performance GPUs (like AMD/ATI) don't come along with GEM very well.
Re: [gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
1. Native framebuffer console resolution on my 1680x1050 widescreen LCD - no more 1280x1024 stretched! (Actually not sure if this is directly due to the kernel updates for Intel/KMS, or just happened to happen at the same time, but still - Yay!) You know, I after some trouble I found a VESA code for my also not so standard 1440x900, so that vesafb happily provided me with native console since 2.6.27 (if not .25) (had a nice program that displayed supported framebuffer modes - what was it ?) 2. Perfectly fast X/virtual console switching - I mean - Wow! I still, from time to time, just sit there switching between the two a couple times just to watch the speed and smoothness - it's amazing... -James I wonder, what are the negatives of moving modesetting to kernel from userspace ? Will we be loosing some functionality (at least temperarily) ? How will, say, choosing mode on external distplay work ? -- Dmitri PogosyanDepartment of Physics Associate ProfessorUniversity of Alberta tel 1-780-492-2150 11322 - 89 Avenue fax 1-780-492-0714 Edmonton, AB, T6G 2G7, CANADA
[gentoo-amd64] unsubscribe
[gentoo-amd64] Re: How do I switch to a window manager?
Steve Herber her...@thing.com posted pine.lnx.4.64.0906170910450.29...@thing.com, excerpted below, on Wed, 17 Jun 2009 09:39:13 -0700: Can somebody answer a question, related to the favorite WM question, how do I change to an alternative window manager? I normally run xdm and update my .xinitrc or .xsession file to do this but I feel that there should be a better way. How do you do it? My better way is to not use a graphical login manager at all, but rather to login at the text login prompt, and start X (and my WM/DE (windo manager / desktop environment) of choice) from there. Whether that's a better way for you or not, of course depends on you, but it Works for Me (tm)! The various DEs and at least some of the WMs should put session scripts in /etc/X11/Sessions, with launchers (like startkde) in the path. You can either use the launchers, or create your own. I create my own launchers as scriptlets that make use of the generic startx. Normally, startx depends on the XSESSION variable as set and exported in either the system scripts (rc.conf, IIRC for baselayout-1 users) or in a user's startup scripts (.bashrc or the like). However, that's kind of limiting since it leaves just one choice. So for each session script in /etc/X11/Sessions, I create a scriptlet, say k4 for kde4, k3 for kde3, g2 if I had gnome2 installed, etc. Each of these sets and exports the XSESSION variable to match the appropriate filename in the Sessions dir, and then invokes startx. Now, with a single short (two- character in the above examples, g2, k3, k4, etc) command, I can start any of the session types I want. =:^) What's nice about this is that once the launcher scriptlets are setup, it's possible to take care of any other housekeeping as necessary, setting up any other environmental vars, whatever. Any commands before the startx will run as X and that environment starts. Any after it will run as it quits back to the text login. Or, make it startx , so it runs in the background and issue the bash disown command, and the script will startx in the background and then terminate, leaving you with a bash prompt again. Then you can do what I do and run . k3, so it runs it in the current shell, and it'll logout after startx as well, thus returning that VT to the login prompt. As can be seen, it wasn't for nothing that I said my system is rather more uniquely customized than most. =:^) But it fits the way I work and is thus the better way for me, which is what counts. And of course Gentoo makes all that customization far easier than most distributions do, making it all the better! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-amd64] How do I choose a second window manager?
Am Mittwoch 17 Juni 2009 15:10:42 schrieb Mark Knecht: On Wed, Jun 17, 2009 at 6:03 AM, Alex Alexanderalex.alexan...@gmail.com wrote: fluxbox is a nice, lightweight, usable WM :) -- Alex Alexander || wired Gentoo QT KDE Herd Tester http://www.linuxized.com Yep. And so small I built it by the time your response came back and am answering your message from within it. Granted, black screen and the menus don't see any of the apps I have installed, so that's the same old problem. Isn't there some app for automatically picking up apps on putting the menu together auto-magically? Cheers, Mark x11-misc/menumaker I use it with openbox, but fluxbox is supported, too. But it's comman-line, not automatic.
[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
James Ausmus james.aus...@gmail.com posted b79f23070906171116v24babcedh47c1c9b5fca39...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 11:16:50 -0700: Just as a note - the Radeon KMS uses a different implementation path than the Intel KMS - Intel, in the kernel, uses GEM for gfx memory management, while Radeon (and Nouveau, and other upcoming) use the new TTM (which is also new for .31) - I don't *think* this will affect how X interfaces with the kernel driver, but, since TTM is newer than GEM (GEM/Intel KMS happened in .29), it might still be a little bit before the wrinkles are worked out. As Sebastian Redi indicated, TTM is actually older. FWIW, from my viewpoint at least, it looks a bit like NIH syndrome (not invented here syndrome) from the Intel guys. Whatever. They didn't like TTM as it was already being implemented for Radeon and some of the other drivers (Nouveau, etc) and came up with their own thing, GEM, which works particularly well with the Intel hardware implementation but not quite as well with other implementations. But for various reasons Intel's GEM hit the mainline kernel first. Meanwhile, the TTM folks continued what they were doing, and now it's hitting mainline, but using the GEM interface (as SR again mentioned). It's all a bit confusing, even for those such as myself who follow Linux developments reasonably closely and have been reading pretty much anything they see on it. As far as the X server interfacing with the new kernel driver, I *believe* that pretty much all the action behind the scenes happens in the X driver itself, with the X server being pretty much unaware of the change (please feel free to correct me if I'm wrong), so, just because the Intel driver has already been utilizing the KMS kernel interface for a little while, doesn't necessarily mean that it will make the Radeon X driver transition any smoother/better/shorter. Well, it's some of both, actually. xorg-server has to support it, but so does the X driver, which with KMS ultimately becomes as I mentioned earlier, not a lot more than a wrapper around the kernel code, with xorg- server in turn interfacing with the wrapper. But since it'll be awhile before it can be assumed that the kernel has KMS drivers on its side, the driver will remain more than a wrapper for awhile, but disable most of itself and only act as a wrapper when KMS is turned on. In addition to that, the first one is /always/ the hardest, and now that it is done, the rest will come easier. So while you are indeed correct that there's some implementation details in the X driver that the Intel driver doesn't help with directly for others (particularly since it went its own way, implementing GEM directly, instead of the GEM interface to TTM that the others are using), that's only one piece of the puzzle. With many of the other pieces, having the first one, Intel, in place and working out the general issues and testing the general idea, means the others have it MUCH easier. 4) Shows up in portage under ~amd64 (Is that the same as ~arch for AMD64?) ~arch means the same regardless of architecture ;) It's ~x86 for IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc. Exactly. ~arch is simply the generic term, while ~amd64 would be the specific version the readers of this list will be concerned with. Dunno - X server 1.6 has been out for quite a while (several months - X server 1.7 is due out in just about 1.5 months at this point), and it just very recently hit the portage ~ tree (not that I'm complaining Devs - I understand that there were issues that would've bit lots of users), so it might be a while before you see Radeon KMS support in the fully stable portage tree - don't hold your breath quite yet. ;) Of course, if your system isn't mission-critical, you could always install the - versions, or at least the ~ versions when they hit, and help move along the debugging/stabilization process, so that they hit the stable tree faster... ;) That's my take on it too. Hopefully it won't be 2 years before stable, but it could well be 18 months, and will almost certainly be at /least/ 9 months for Radeon, 6 months for Intel, and a year for others. It's a big change and for Intel users so far, has been /anything/ but smooth. Having run the Intel KMS kernel/fbcon/X driver for a little while now, I can say that 2 things *really* stand out to me (at least from my usage model): 1. Native framebuffer console resolution on my 1680x1050 widescreen LCD - no more 1280x1024 stretched! (Actually not sure if this is directly due to the kernel updates for Intel/KMS, or just happened to happen at the same time, but still - Yay!) Well, the radeonfb drivers have existed in the kernel for years, so for older radeon users at least, they've had the possibility of full/native resolution framebuffer for some time. And for those without a specific native hardware fb,
[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
On 06/17/2009 10:19 PM, Dmitri Pogosyan wrote: 2. Perfectly fast X/virtual console switching - I mean - Wow! I still, from time to time, just sit there switching between the two a couple times just to watch the speed and smoothness - it's amazing... I wonder, what are the negatives of moving modesetting to kernel from userspace ? Will we be loosing some functionality (at least temperarily) ? How will, say, choosing mode on external distplay work ? No negative sides to it, really. Speed will also benefit (not directly from KMS but rather from TTM/GEM) since the biggest problem with the open source drivers right now is the lack of a memory manager (this is the main reason why the closed source drivers perform better by an order of magnitude, even though they have the memory manager in user space). I'm not sure about the mode for external displays. The configuration will probably still happen at the same place, though under the hood the work will be done by the kernel.
[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
Dmitri Pogosyan pogos...@phys.ualberta.ca posted 200906171919.n5hjj7007...@webmail.phys.ualberta.ca, excerpted below, on Wed, 17 Jun 2009 13:19:07 -0600: I wonder, what are the negatives of moving modesetting to kernel from userspace ? Will we be loosing some functionality (at least temperarily) ? How will, say, choosing mode on external distplay work ? The biggest negative for the Intel users has been the rough ride, and yes, some functionality is certainly lost during the transition. It's about done for the Intel users but just starting for Radeon users. Let's see if I can find the (Intel dev) blog I read on that... http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/ The date posted was April 24, 2009 Excerpts... Because all of these changes cross multiple projects (X/Mesa/Linux), we’ve tried to make sure we supported all of the possible combinations. Let’s see what options we’ve got: Mode Setting 1 User Mode 2 Kernel Mode Direct Rendering 1 None 2 DRI1 3 DRI2 Memory Management 1 X server + Old-style DRI 2 GEM 2D acceleration 1 None 2 XAA 3 EXA 4 UXA Pick One From Each [Category] With 2 × 3 × 2 × 4 = 48 combinations, you can imagine that: Some of them can’t work together Some of them haven’t been tested Some of them haven’t been tuned for performance Some work well on i915, and poorly on 965GM Others work well on 965GM and poorly on 855 None of them (yet) work perfectly well everywhere The obvious result here is that we’re at a point where application performance goes all over the map, depending on the hardware platform and particular set of configuration options selected. Light at Tunnel’s End The good news is that our redesign is now complete, and we have the architecture we want in place throughout the system — global graphics memory management, kernel mode setting and per-window 3D buffers. This means that the rate of new code additions to the driver has dropped dramatically; almost to zero. Going forward, users should expect this ‘perfect’ combination to work more reliably, faster and better as time goes by. End excerpts... As I said, it was quite the rough ride. But that was nearing the end of April, and things have been better since. Hopefully Radeon won't be quite as bad. We'll see I guess. As for the last question, the example of external display mode, at minimum, it shouldn't regress (except for temporary regressions of the type Keith explained in his blog). The xorg folks have put an enormous amount of work into hotplug, and they won't be letting that go just for this. I'm not entirely sure on this, but from my understanding, X will still be in control of the modes. It'll simply use the kernel's EDID/DDC detection instead of its own to see what modes are there (and whether any additional modes as configured will work within the detected card and monitor parameters) and to do the actual mode switches, but it'll be telling the kernel what mode to use, tho the default will be native/ primary mode for both the CLI/text framebuffer and X initially, thus no mode change switching between them. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-amd64] How do I choose a second window manager?
Maybe I am missing something, but what is wrong with 'fluxbox-generate_menu' ? (it's part of fluxbox itself) -- Joseph Booker signature.asc Description: PGP signature
Re: [gentoo-amd64] How do I choose a second window manager?
On Wed, Jun 17, 2009 at 2:48 PM, Joseph Bookerj...@neoturbine.net wrote: Maybe I am missing something, but what is wrong with 'fluxbox-generate_menu' ? (it's part of fluxbox itself) -- Joseph Booker You're not missing anything from my POV. I didn't know about it. It may address my issues with fluxbox from 5-8 years ago when those sorts of tools didn't exist. However, I've run fluxbox and could have gone down that path without querying the list. (But having done so has allowed me to find out about tools such as you mention. Anyway, I'm wondering what sorts of new things folks are using, why they are using them, what they like about them, etc. Mainly just poking around for ideas. Thanks, Mark
Re: [gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
As I said, it was quite the rough ride. But that was nearing the end of April, and things have been better since. Hopefully Radeon won't be quite as bad. We'll see I guess. I am with Intel laptop since last September and passed through all of that. It actually was not that bad, aspecially given that I don't need 3D functionality much (although I tried to keep it in best working state) As for the last question, the example of external display mode, at minimum, it shouldn't regress (except for temporary regressions of the type Keith explained in his blog). The xorg folks have put an enormous amount of work into hotplug, and they won't be letting that go just for this. I'm not entirely sure on this, but from my understanding, X will still be in control of the modes. It'll simply use the kernel's EDID/DDC detection instead of its own to see what modes are there (and whether any additional modes as configured will work within the detected card and monitor parameters) and to do the actual mode switches, but it'll be telling the kernel what mode to use, tho the default will be native/ primary mode for both the CLI/text framebuffer and X initially, thus no mode change switching between them. Interestingly, I don't care much about VT switching (well, no flickering is nice, but I switch perhaps once every few days), nor security (I use X for 16 years already from the epoch of X-terminals, and never really heard of any specific case when X was used to break in mind doing any damage, again its nice to be safer, but overall it seems like red herring) nor that much about framebuffer resolution because I got may native 1440x900 from vesafb just fine. Multimonitor functionality is, however, a must. Think laptop as a presentation tool. So I wonder how kernel will deal with two different resolutions on separate pipes, whether one can force it to a specific mode (which sometimes needed with this bloody projectors), I mean all this xrandr type mode-related functionality. Hopefully this is all well though through and there will be no extended period when it somehow does not work.
Re: [gentoo-amd64] How do I choose a second window manager? [FROM XFCE]
On Wed, Jun 17, 2009 at 6:18 AM, Martin Herrmanmar...@herrman.nl wrote: On Wed, Jun 17, 2009 at 3:10 PM, Mark Knechtmarkkne...@gmail.com wrote: Yep. And so small I built it by the time your response came back and am answering your message from within it. Granted, black screen and the menus don't see any of the apps I have installed, so that's the same old problem. Isn't there some app for automatically picking up apps on putting the menu together auto-magically? Cheers, Mark The Xfce 4 Appfinder is part of the Xfce 4 Desktop Environment and features application search on the whole system. It searches for .desktop files based on the freedesktop spec and makes an index of the found apps. Source: xfce website: http://www.xfce.org/documentation/4.2/manuals/xfce4-appfinder Does Gentoo use these .desktop files? OK - I emerged XFCE4 and am writing this message from there. It finds all my apps and the menues seem to be arranged reasonably so I suspect that it might work nicely over time. I haven't had time yet to check any real performance issues - xruns using Jack, or other things that might be important to me, but it seems like a reasonable little setup and it feels responsive starting up. One thing I'm not finding is it doesn't seem to allow a multi-file drag on my desktop to change icon positions. That a minor disappointment. Certainly not a big deal for my life, but I wonder how you mive 20 files created by some audio program to a new folder using the GUI? I thought I was running 1600x1200 in Gnome but XFCE is only offering as high as 1280x1024. I'll check that later and I'm probably incorrect. In general it might be a replacement for Gnome. Feels good. If I had to complain about something it might be that the default setup doesn't seem very sexy. XFCE might benefit from some marketing input. I'll have to spend some time learning how I might improve things a bit. Thanks, Mark
[gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31
Dmitri Pogosyan pogos...@phys.ualberta.ca posted 200906172226.n5hmq9o11...@webmail.phys.ualberta.ca, excerpted below, on Wed, 17 Jun 2009 16:26:09 -0600: Multimonitor functionality is, however, a must. FWIW, I'm in 100% agreement with you. I run dual 1920x1200 stacked for 1920x2400, and if the new drivers don't do that, I'll be back to the old drivers faster than fsck! But I don't expect it to be a problem, because while it's relatively uncommon to run dual desktop monitors and probably always will be as laptops are the majority seller now, there's a LOT of folks now days that will flat call it broken if their laptop can't work with both the internal and external monitors at the same time! In fact, that was and remains the big push behind RandR and input hotplugging as well, and now that they've got it working reasonably well, they're NOT going to go back to having it broken, or people will be walking away, as I said, faster than fsck! Plus, enough of the xorg devs work with laptops and do enough mobile warrioring that it's not as if they don't have the hardware or the need to keep it working just for themselves, because they do. So I just don't see it as even a possibility that they'll implement it without that. Still it's a a very good question, one that while it's important to me, I hadn't thought of, simply because I /don't/ believe it within the realm of reason. So I'm glad /someone's/ thinking about it! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-amd64] Re: How do I choose a second window manager?
Mark Knecht markkne...@gmail.com posted 5bdc1c8b0906171350n10d32d2at83600ee6b31ba...@mail.gmail.com, excerpted below, on Wed, 17 Jun 2009 13:50:17 -0700: All of this probably make sense, and I'll do a little study on the matter, but when running Ardour recording a band playing a live gig it's a one-shot, you gotta get it right sort of event. There is only one performance. I did enough of that years ago (80s) that I understand what you are talking about. However, back then, it wasn't computerized, or more correctly, they were just starting to really get into it, with live computer processing at concerts, etc, but that was expensive pro stuff at the time, way past my piddly little running the mixer for the praise and worship at the church level. But between that and my general computer knowledge now, I appreciate the effect latency has on a product, and why there simply can be no compromise. I didn't and don't expect that you /would/ run an emerge while doing that, no way, Jose, as they say, but was simply illustrating the point that you /could/ or /almost/ could anyway. Not that you ever /would/, but that if it's good enough to deal with /that/ sort of thing, it should be a walk in the park for the stuff you /will/ be wanting and needing it to do. Anyway, the topic of sound engineering is still interesting enough to me that I love to hear or read people that are still in it talking about it. So I really appreciated your post. Plus, I know enough about it from then, and about computers now, that if the opportunity/need comes my way, I could jump back into it again, and then I /would/ be using all I've read about Jack, Ardour, low-latency kernels, etc, putting it all to use and asking people like you for pointers. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
