What is Reddit's opinion of
X11?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
No, they never promised to open their drivers. They even explicitly said that their binary blob (fgrlx) will probably never be opened up. Instead, they did exactly what the Linux community asked them to do: release hardware documentation of all of their graphics cards. "We can write the drivers ourselves!", said the Linux community. Turns out that writing graphic card drivers is hard, especially considering all the opengl hacks which are needed to function properly. So after releasing the hardware documentation, the moaning shifted to complaining about "AMD not developing an open-source driver". And so they did. They hired people to work on the open-source initiative full-time, which paid off. In kernel 4.2 for example, 36.8% of the changes in the kernel were made by AMD alone.
Not only that, but AMD has been a major player in userland where it rewrote a lot of code (setting the stage so to speak) in mesa an other software packages. Saying that 'opening up' only happened as of lately is wrong, and it irks me. The Linux community is an entitled bunch, which will never stop complaining even when companies do exactly what they asked for.
Whenever a window redraws part of its contents, the compositor needs to know which rectangles it touched to know where it should redraw. The X11 DAMAGE extension traditionally provided this information. Since then, the name "damage" to mean "set of rectangles that have been touched" has been carried over into Wayland and EGL.
From: Florian Weimer <fw () deneb enyo de>
Date: Thu, 19 Jan 2012 20:18:37 +0100
>I recently found out that it is possible to kill a screensaver/screen locker program on the latest version of Xorg (1.11 shipped with archlinux, debian wheezy..) using the Ctrl+Alt+Multiply key binding.
This used to be, uhm, common knowledge:
| Option "AllowDeactivateGrabs" "boolean"
| This option enables the use of the Ctrl+Alt+Keypad-Divide key
| sequence to deactivate any active keyboard and mouse
| grabs. Default: off.
| This option enables the use of the Ctrl+Alt+Keypad-Multiply key
| sequence to kill clients with an active keyboard or mouse grab as
| well as killing any application that may have locked the server,
| normally using the XGrabServer(3x) Xlib function. Default: off.
| will allow users to remove the grab used by screen saver/locker
| programs. An API was written to such cases. If you enable this
| option, make sure your screen saver/locker is updated.
<http://www.x.org/archive/X11R6.8.1/doc/Xorg.1.html>
The API in question appears to be XF86MiscSetGrabKeysState:
<http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/XF86Config.man?hideattic=0#rev1.6>
I spent a good few minutes running around trying to find some big X announcement I missed that everyone would be talking about before I realized you were using that as a variable.
http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf
Page 3.
Vulkan and OpenCL drivers remain proprietary until some magical time in the future when they open source them, which almost certainly means never. Yet we don't even have the proprietary driver. Don't worry guys, just trust AMD, they will respect our software freedoms eventually!
> Releasing drivers as open source could give their competitors information on how the hardware works.
FOSS developers do not ask for code, they ask for programming specifications, such these documents from AMD/ATI:
There is no information therein about how the hardware works. There are no clones of AMD/ATI GPUs on the market as a result of the publication of these programming specifications.
Even in the case of Intel, who actually do release open source code rather than programming specs ... there are no clones of Intel GPUs on the market as a result of the publication of open source code.
The nv driver was at least partially maintained by nVidia to provide limited 2D functionality (see the COPYING file and the X.org wiki). nVidia will not provide specs/code for advanced 3D functionality, hence the nouveau reverse engineering effort. There's a good wiki article that outlines all of the details
You are aware that we heavily optimized KWin by e.g. port to XCB (http://www.x.org/wiki/Events/XDC2014/XDC2014Graesslin/ ), introduce the new KDecoration2 (http://blog.martin-graesslin.com/blog/2014/12/looking-at-the-memory-improvements-of-kdecoration2/ ), reduced the number of roundtrips for managing a window (http://blog.martin-graesslin.com/blog/2015/01/kwin-on-speed/ ). We were able to put KWin on a phone and it's not a bottleneck, so what are you talking about with KWin being a heavy component?
You hardly find a window manager which uses XCB (I'm aware of 3 and KWin being the only composited) and that makes a huge difference.
But if you are happy with Xfce: great for you! Praise Xfce for what they do, but don't do uninformed statements about other projects.
Disclaimer: I've only worked on gdm, not on any display managers, so I can't speak for anything but that, but I think it's mostly the same for the other two.
It used to be that Xorg needed to be run as root (this changed within the last year or so). So some program that runs as root needs to run Xorg. That's what a display manager does. A display manager starts the X server, monitors it, restarts it when it crashes, and other things like that. Display managers also handle login and session management as part of that -- kdm/gdm/lightdm have the concept of a "greeter" which is a special X server session that lets the user log in from it, which also handles features like autologin and timed login. A good portion of gdm's codebase isn't about X server management, that's just a file or two, it's about complex session management features and interacting with the PAM stack.
startx is a very primitive form of display manager, written in bash. I'll let you read the source code, including the top comment.
http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp
There's plenty of other things that some display managers implement, like integration with XDMCP for remote login and remote display.
> It's not easy, because none (meaning: no major distro) is doing it. And why?
Because they're not pretending to be secure (short of projects like QubesOS), because security tends to be inconvenient - for instance, if you sanboxed GIMP then your color picker tool would break. And as I said, the solution to security is to only run programs from the repository.
Unless you misinterpret what I said as "sandboxing is ultra-quick and user-friendly" as opposed to "there's nothing in X stopping you from doing it, which means the solution will be an order-of-magnitude faster than literally rewriting everything as Wayland".
>If you would nest your SuperPassKeep into a nested X server, this would bring you nothing, because the main X still get's every character. So you'd need to put EVERY application into a nested X and make somehow sure that no application ever connectes to the main X. The first would eat up lots of resources
Yes, that's correct. Which is why nobody does it unless they really need security, which nobody really does.
>and for the second there are not really mechanisms
Check "Keyboard Security" on this page.
>When it would be so easy or doable, I'd expect that the next month Debian, Fedora, RedHat, SuSE or Ubuntu implements this.
Again: why would they. At the end of the day, if you think something is untrusted then you shouldn't run it on your computer. This is what the repository is for. And again, it would not be a complete security solution anyway (be it X11 or Wayland)!
That's the protocol version; it's been stable since 1987. The nice folks at x.org have thoughts on what would go into X12, but since it would be backwards-incompatible, you might as well just move to Wayland or whatnot. The actual features have been developed piecemeal, in drivers or extensions, and to the extent that this shows up in the version history, it's as "katamaris", roll-up releases every eighteen months or so (the current one is overdue). Wikipedia has a good overview.
It's a lot more complicated than this. There are technical problems on a modern computer (e.g. use of keyboard metakeys when the screensaver is on) that X can not solve without being completely re-written. There are huge sections of the X11 code base that are completely obsolete and will never be used again (some never were used). For example, no one uses the built in drawing features and just blits raster blocks to the X clients for maximal compatibility. Xprint -- ever even heard of it? Font handling on X is ridiculous. There is the question of going through a network protocol stack just to play a game on your local PC. One could make an argument for the development of X12, but that's not what Wayland is: it's a complete re-thinking of the linux graphics stack which will allow for much greater display server agnosticism, if you like.
1) R600 refers to older generations of cards. I think it starts with the HD4xxx series. Radeonsi is for newer cards starting with Northern Islands, which is I think the HD7xxx series. See here for more details: http://www.x.org/wiki/RadeonFeature/
2) you'll be using radeonsi 3) mesa doesn't relate to the kernel. This will be in the next release, version 12, that's out in almost 3 months. It'll be in the next versions of all major distros. You'll also need the next version of the LLVM compiler for compute to work. But that'll again come out before the next distro releases.
4) I think you could donate to free desktop.org. otherwise many developers are paid (Intel and AMD) and can't take donations.
5) depends on your OS. Building from source is the only cross-distro way to do it but it's quite an undertaking.
Alex Deucher is going to talk about "AMD's New Unified Open Source Driver" on XDC2014:
>AMD is moving to unify it's current open and closed source Linux drivers over a common, shared, open source kernel driver. > >This talk will provide an overview of our plans for the future and the challenges we face as we move forward.
You need to specify iso10646 in the CHARSET_REGISTRY part of your X Logical Font Description. For example:
--freesans-medium-r---------iso10646-
This allows you to access all the extra symbols available in your font.
Note that 'bar' can only use X Core Fonts, which are located in a different place to usual fonts, so your usual fonts might not be available. There are however the two useful commands mkfontscale and mkfontdir from the xfonts-utils package (or whatever it's called on your system) which allow you to copy fonts to the right places. I've written a short blog post explaining what to do here.
Follow the progress of the Radeon open source drivers on this page: http://www.x.org/wiki/RadeonFeature
Orange represents "Work In Progress". A "G" superfix means for the Gallium 3D version of the driver, whereas a "C" superfix refers to the classic Mesa version.
Ubuntu 11.04 shipped with the Gallium 3D drivers by default for most ATI cards.
Arch Linux is also very up-to-date.
Textured Xv is done, but Video Decode (XvMC/VDPAU/VA-API) using the 3D engine is still a work in progress. This work, along with OpenCL support, is amongst the projects for the Google Summer of Code this year.
http://www.phoronix.com/scan.php?page=news_item&px=OTM3Nw
http://www.phoronix.com/scan.php?page=news_item&px=OTM3OA
Documentation like this?
http://www.x.org/docs/AMD/old/si_programming_guide_v2.pdf
AMD started releasing detailed documentation quite a while ago for the open source driver development on Linux, which has made decent progress as of late.
I think you are unfair about i3 being slow and heavy on resources. In practice i3 uses only a tiny bit more memory than i3 or xmonad, and a lot less than awesome or even openbox. On top of that, i3 has even less CPU usage due to using XCB over Xlib. This is one of the reasons why 'Low-line-count' != 'Faster'
> You customize it by editing a config file which slows it down a little more.
The program reads the file once during startup. Run-time speed is unaffected. Even if it had to open 100 files, it would only affect the startup time. Making a connection to the X11 server is where most of the startup time goes to anyways for most small WMs.
In any case, there is probably going to be no noticeable difference in the performance of any of these WMs, even on a 10 year old laptop.
You could always work on bringing X to the GBA :)
Probably not even possible with the hardware constraints of the GBA and I'm sure it would be unreasonably slow if it did work, but it would be quite impressive IMO.
I don't know much else that involves low-level programming and graphics that isn't video games (neither are my areas of expertise), but some sort of window management system would definitely be a nice challenge.
The videos are also available on youtube.
I highly recommend watching the talk about "AMD's New Unified Open Source Driver" by Alex Deucher first. Some interesting segments can be seen at 6:50-7:40 and 17:50-19:40.
Discuss! =)
You can boot to console, but without X you wont be able to run graphic applications. A tiling WM is what you need. Start up a very minimal tiling WM, and have a terminal window open by utilizing your autostart service (I use either .xinitrc or .ratpoisonrc [since I use ratpoison])
X.Org needs to be running for chrome to open.
Edit: if you boot to console, you can at least use tmux to get split consoles and elinks to view the web. I'm not sure that is what you want since you seem to want to use graphic applications rather than text based.
I never had any issues with power management except on my laptop's hybrid graphics, where I had to resort to some really crap scripts to manage things.
Anyway, check this http://www.x.org/wiki/RadeonFeature
Scroll down until you get to power management for the relevant architecture.
The Gallium3D drivers for AMD/ATI cards, which are part of the Linux kernel and hence they ship with Linux distributions, and which are installed and automatically configured by default, without requiring any command-line-fu at all, and which work even following a kernel update ... these drivers are not "ATI stuff".
These drivers are written by Xorg developers, using programming specs supplied by AMD/ATI. The drivers are not written by AMD/ATI, although some AMD/ATI employees do contribute.
Here are the programming specifications which AMD/ATI released: http://www.x.org/docs/AMD/
Here is the Features page (updated regularly) which shows the ongoing features implement by the Xorg Gallium3D and classic Mesa drivers.
http://www.x.org/wiki/RadeonFeature
The newer Gallium3D drivers from Xorg are the ones now shipped by default in recent Linux distributions. They are part of the Linux kernel itself.
Xorg developers know a lot more about writing Linux drivers than either AMD/ATI employees or nvidia employees, without a shadow of a doubt. No contest.
Xorg drivers for AMD/ATI GPUs do not "just randomly fails/has issues". To claim so is pure and utter FUD on your part, and you should be called on it for trying to give out such misinformation to fellow redditors who asked or who are interested in this question.
AFAIK there's also an effective hard X11 <em>protocol</em> level virtual screen size limit as the various important x/y/width/height fields in the core protocol are defined as "INT16" or "CARD16" (i.e. 16-bit signed or unsigned values, using the X11 protocol spec terminology).
32767x32767 is typically still larger than an ordinary single gfx card supports of course, and at the time X11 was designed, that was of course really pretty damn huge. But it's no longer so outlandish - like one could imagine a bank of gfx cards xinerama'd together driving a video wall of 4k displays could conceivably hit it, we're only talking gigs of framebuffers.
So the rather newer Wayland mostly uses 32-bit values - however sometimes they are split 24/8 as a "fixed" (i.e. signed fixed point) type, so let's say signed 24-bit i.e. 8388607x8388607. So still much larger, should do for a while.
If open-source drivers work, and work well, then stick to them, because they're only going to get better. I can tell you from personal experience that the annoyingly-noisy fans are a problem on the 270X too, but it's a known issue, and is only because of an un-implemented feature to do with fan speeds*, so at some point in the future, that will be patched.
If open-source drivers don't work, and fglrx does, then use fglrx, and check back next year.
It's up to you, but unless radeon bugs you much more than fglrx does overall, you should stick to radeon.
*Specifically, see this page - "Dynamic Power Management (DPM)" is listed as a WIP, as opposed to "TODO", "DONE", or "MOSTLY".
Have you given consideration on using mesa's open source Gallium3D drivers? I haven't tested it myself on my own HD 4850, but the RadeonProgram support matrix does list Team Fortress 2 as playable.
- Stick with the drivers in the default repositories unless you are feeling adventurous. And don't use any 'random' PPA. The final bullet below details an excellent and long lived PPA for bleeding edge builds for Ubuntu.
- Here is the Mesa/opensource driver info for Radeon cards: http://www.x.org/wiki/RadeonFeature/ . It has what they call a "decoder ring" so you can find out which driver you need among other cool things that Mesa offers. The decoder ring states you are using a Southern Island card which uses the radeonsi driver.
- fglrx is the closed source driver brought to you by AMD
- If you feel like trying the bleeding edge drivers (both open/closed source), there is one (and only one) PPA I would recommend, the xorg-edgers PPA: https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa
Good luck, enjoy.
Also, don't call it "X Windows".
>The X.Org Foundation requests that the following names be used when referring to this software: > >- X >- X Window System >- X Version 11 >- X Window System, Version 11 >- X11
AMD don't write most of the open source drivers. Most open source drivers are written by independent developers, using programming information provided by AMD.
Here is the progress so far on features: http://www.x.org/wiki/RadeonFeature
AMD did however release open source drivers they had written for the new AMD Fusion line of APUs.
AMD recently announced they were hiring 1000 developers with open source (Linux) skills.
What more could you possibly want? After only minimal optimisation efforts have commenced, performance of open source drivers in some areas is beginning to approach (and occasionally even eclipse) the closed source proprietary fglrx driver.
NOTE: Closed source drivers for Linux from both nVidia (nvidia driver) and AMD (fglrx driver) will not work with KMS and kernel-based graphics memory mangement, both of which are required for Wayland. Since Wayland is the up-and-coming replacement for the display server on Linux, this will mean that in the future closed-source graphics drivers will no longer work.
If someone actually cared about that, though, they could just write an X11 security module to disallow key logging.
It's not very new thing.
Sort of right.
fglrx is the AMD proprietary Catalyst Linux driver and contains both the userspace and kernel parts.
For open source AMD drivers, there are 2 different kernel drivers and a few different user space drivers, which vary based on your hardware:
kernel (low level hardware interaction):
- radeon - this covers cards up through Sea Islands (OG Radeon - R9 390X, minus R9 285 and R9 380)
- amdgpu - this covers Volcanic Islands and up (R9 285, R9 380, Fury, Fury X, R9 Nano)
user space (high level hardware management, abstractions like OpenGL, OpenCL, etc):
- radeon, r200, r300g - OG Radeon up to HD 2300, mostly of historical note nowadays
- r600g - r600 through Northern Islands (HD 2400 - HD 6990, HD 7000 < 7750)
- radeonsi - Southern Islands and up (HD 7750 - Fury)
RadeonFeature has all the gory open source details.
You're basically going to be dealing with one of these combinations:
- fglrx/catalyst (HD 5000 and up)
- radeon/r600g (HD 2400 - 6990)
- radeon/radeonsi (HD 7750 - R9 390X)
- amdgpu/radeonsi (R9 285, R9 380, Fury, Fury X, R9 Nano)
At some point you might be using:
Performance is generally going to be better with Catalyst. It supports OpenGL 4.4 and is geared towards performance. The latest open source drivers in the upcoming Mesa release are getting a lot better, though. Of course, Catalyst has its share of problems as well: it tends to lag on kernel/Xorg release support, 2d performance is not great, can be buggy as well.
Edit: Formatting
Wrong, they once stated that they had no plans of supporting Wayland, nowadays they are working on supporting both Wayland and Mir.
http://www.x.org/videos/XDC2014/RitgerEGLNonMesa.webm
http://www.phoronix.com/scan.php?page=news_item&px=MTgxMDE
From man synaptics
Option "TouchpadOff" "integer" Switch off the touchpad. Valid values are:
0 Touchpad is enabled 1 Touchpad is switched off (physical clicks still work) 2 Only tapping and scrolling is switched off When the touchpad is switched off, button events caused by a physical button press are still interpreted. On a ClickPad, this includes software-emulated middle and right buttons as defined by the SoftButtonAreas set‐ ting.
Property: "Synaptics Off"
If that doesn't work, set the Areas to some nonsense or something.
Do you even use the synaptics driver?
It worked! Here's how I did it.
I copied the 50-synaptics.conf file from /usr/share/X11/xorg.conf.d/ to /etc/X11/xorg.conf.d/ (if the folder does not exist then mkdir) and added the line
> Option "TapButton3" "2"
under the part that starts with
> Section "InputClass"
You can find the details on different options in this manual:
http://www.x.org/archive/X11R7.5/doc/man/man4/synaptics.4.html
What exactly stops people from sponsoring internships for men in open source?
And why do they want to tell others what to do with their money?
Quit whinging about what other people do, instead build up your own charity, because, whilst IT is male dominated, there are plenty of men who really would benefit from internships.
And it looks like X.org is doing that as well, see here: http://www.x.org/wiki/XorgEVoC/
I won't include that in the master branch but I can give you hints on how to achieve it. Currently, the borders are drawn using a graphic context over a pixmap (setborders function). You could play around changing xcb_rectangle_t by some arcs to get a round effect. There are some examples on how to draw with xcb here: http://www.x.org/releases/X11R7.6/doc/libxcb/tutorial/index.html In theory you can create borders in whatever shape you like.
Sure, but you have that problem today under X11 too. Certain WMs might not support certain hints. There's a series of standards called the ICCCM and EWMH which tell WMs and applications how to behave. There's no reason the same can't be done for Wayland.
Compatibility and compliancy is a social issue, not a technical one.
Before everyone gets too hyped up about this, bear in mind it only works for their newest chips (bottom of this list) — anyone with a pre-2014 APU has to make do with the current half-implemented OpenCL 1.1 in the radeon driver, unfortunately.
Multiseat might be what you are after. So you have 2 sets of keyboard/mouse/monitor with independent logins http://www.x.org/wiki/Development/Documentation/Multiseat/
Also note that most Xeons do not have integrated graphics.
You shouldn't need to install any drivers. The standard drivers perform on par with the last supported Catalyst drivers. The last Catalyst release for the HD 4XXX drivers was 13.1. The current version is 14.3.
TL;DR Just use the included drivers. They work the same, work OOTB, and are supported.
Prepend four spaces to get code to be code-like:
#!/bin/sh
if [ -n "$(xrandr | grep 768x1024)" ]; then xrandr -o normal xsetwacom set "Serial Wacom Tablet stylus" Rotate NONE else xrandr -o right xsetwacom set "Serial Wacom Tablet stylus" Rotate CCW fi
To the OP: see XRandR
> Except any and all 3D acelleration.
What on earth are you on about? The open source Radeon driver does 3D acceleration. Performance isn't up to the level of the closed source driver just yet, but it does basically work.
Don't take my word for it, check this out:
http://www.x.org/wiki/RadeonProgram For my own card, which has an R700 GPU, there are only four entries marked blue (it works, but has serious graphical errors), everything else is either green (works perfectly), gold (works but has minor rendering issues), or grey (status has not been reported to the website).
Not everything works yet, but this changes very rapidly. For example, check this out: http://www.phoronix.com/scan.php?page=news_item&px=OTQwOA
More discussion here: http://phoronix.com/forums/showthread.php?27934-Working-r600g-games-list
Enjoy!
This is pure bullshit. Have you seen http://www.x.org/wiki/RadeonFeature and http://www.x.org/wiki/RadeonProgram ?
ATI support is awesome. The binary driver might be bad (not so much atm) but the open source driver is by far better than nvidia's (nuoveau).
>So about 30 minutes ago AMD's Matthew Tippett and John Bridgman handed me a CD containing the initial 2D specs for M56 and rv630 without any NDA. They then gave CDs to anyone else in the room and they are now available at http://www.x.org/docs/AMD
>This is a great initial step forward in the open source graphics driver story, since AMD rang me about 3 months and asked me to help out on setting a direction for this project I've been looking forward to this day.
>Novell/SuSE are working on a driver based on these docs which should be available in the next week or so.
>Big thanks to AMD for reopening dealings with the open source community, and I hope to be able to bring the good news as it happens here.
---9/13/07 02:21 am airlied
> So about 30 minutes ago AMD's Matthew Tippett and John Bridgman handed me a CD containing the initial 2D specs for M56 and rv630 without any NDA. They then gave CDs to anyone else in the room and they are now available at http://www.x.org/docs/AMD
>This is a great initial step forward in the open source graphics driver story, since AMD rang me about 3 months and asked me to help out on setting a direction for this project I've been looking forward to this day.
>Novell/SuSE are working on a driver based on these docs which should be available in the next week or so.
>Big thanks to AMD for reopening dealings with the open source community, and I hope to be able to bring the good news as it happens here.
---9/13/07 02:21 am airlied
I don't know all the gestures, but synclient supports way more than I ever needed. Here's a sample.
fb sets the total resolution. For example if you have two 1920x1080 monitors and want them to be displayed side-by-side you'd set it to at least 3840x1080 -- that's 1920 * 2 x 1080. Panning lets you use a resolution that's higher than what your monitor supports but only show it in a resolution it does support. For example if I set my 1920x1080 monitor to 2560x1600 with panning enabled I would see a 1920x1080 area of the overall display and could pan over the entire 2560x1600 picture as I move the mouse.
From the xrandr man page:
--fb widthxheightReconfigures the screen to the specified size. All configured monitors must fit within this size. When this option is not provided, xrandr computes the smallest screen size that will hold the set of configured outputs; this option provides a way to override that behaviour.--panning widthxheight[+x+y[/track_widthxtrack_height+track_x+track_y[/border_left/border_top/border_right/border_bottom]]]This option sets the panning parameters. As soon as panning is enabled, the CRTC position can change with every pointer move. The first four parameters specify the total panning area, the next four the pointer tracking area (which defaults to the same area). The last four parameters specify the border and default to 0. A width or height set to zero disables panning on the according axis. You typically have to set the screen size with --fb simultaneously.
Christopher Tronche has an online version of The Xlib Programming Manual.
Most people these days will want to use a higher-level toolkit like Gtk+ or Qt, not raw Xlib, for most of the GUI programming (Xlib hasn't changed that much since the '80s, and you will get a GUI that looks like it belongs on an '80s black-and-white Sun workstation if you use it alone). I find that it's useful to know how the X protocol works, because that's what the toolkits translate to, and how to use X extensions like XInput2 or so forth, but even though I've done a lot of weird X hacking (I had a college thesis on X security by proxying requests, I've had to debug issues in the X server, etc.) I've never found it useful to write an entire program in raw Xlib.
If you want to know how X extensions work, there's documentation on X.org, under the "Developer documentation" section. (Oddly, the easiest way to get to it is to go to x.org, click "Documentation", and click "User documentation".)
Simple. Firstly, make sure fglrx is completely gone: https://wiki.archlinux.org/index.php/AMD_Catalyst#Uninstallation
Compile the open source driver by hand, and if you can, install the latest version of mesa. These are the instructions for the driver:
git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati
apt-get build-dep xserver-xorg-video-ati
./autogen.sh --prefix=/opt/xorg
make
sudo make install
Then add the following lines to your /etc/X11/xorg.conf:
Section "Files"
ModulePath "/opt/xorg/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection
At the same time, make sure you see Driver "radeon". Then add the following, under Section "Module":
Load "dri"
Load "dbe"
Load "glx"
Load "extmod"
Then under Section "DRI"
Group "video"
Mode 0666
Then cd to /etc/X11/xorg.conf.d/ and create a file called 20-radeon.conf, with the following text: Section "Device"
Identifier "radeonVGA"
Driver "radeon"
Option "AccelMethod" "Glamor"
Option "DRI3" "on"
Option "EnablePageFlip" "On"
EndSection
Then, to prevent autoconfiguration from fucking shit up, run sudo chattr +i /etc/X11/xorg.conf
Here is my xorg.conf: http://pastebin.com/aE3e21Bn
Enjoy full 3D acceleration and disregard the shills telling you to use proprietary software.
To build libdrm and mesa (in this order), http://www.x.org/wiki/radeonBuildHowTo/ scroll down.
I'm curious did you have any success with Crouton?
I just bought an C100P and like it - except that I couldn't get Crouton to work. I keep getting:
"(EE) No devices detected. Fatal server error: no screens found"
The log file says: "(EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found"
I can find both messages on the FAQ page (http://www.x.org/wiki/FAQErrorMessages/#index8h2) but am still new enough that I don't know how to correct them ...
Was hoping you had success and could help me out. If not I think I'm going to follow the instructions to install from external storage.
See: http://archlinuxarm.org/platforms/armv7/rockchip/asus-chromebook-flip-c100p
It's not unthinkable that this is the reason nvidia suggested a different set of extensions than wayland proposes. See the presentation during XDC2014 ( http://www.x.org/wiki/Events/XDC2014/XDC2014RitgerEGLNonMesa/nvidia-and-compositors.pdf )
Without working drivers to experiment with it is hard to say, but my gut reaction says that I'd prefer these sets of extensions to the EGL_WL_ ones.
>It's likely a permissions problem since starting an X server requires a privileged user.
Xorg can be ran as a normal user, but it does need root privileges to access input device nodes in /dev/
see http://www.x.org/wiki/FAQMiscellaneous/#index2h2 for how that works
as for the problems at hand, a "flashing desktop with no menu" is a weird thing
a look at X-s logs would give the required information on debugging this
this logs should be /var/log/Xorg.*.log
Tips? As I don't have ATI hardware I can only give you the generic tip: try the open source ati driver, unless your card is poorly supported.
You picture is indicating that your videocard actually outputs RGB. You need to tell it to switch to YPbPr. Unfortunately the option to do so on linux is driver specific, and quick googling suggest that radeon driver doesnt have one. Try
xradnr --prop and look for SignalFormat or SignalProperties. You may try to change them with
xrandr --set property value look here http://www.x.org/releases/X11R7.7/doc/randrproto/randrproto.txt for possible values
Doesn't have the toolbar, connecting the blocks is not as easy/convenient as in the Windows version, crashes frequently, looks ugly in general, performance is crawling, need a third party software (X windows system) etc. I believe it's gotten significantly better since R2014a .
It's still a bit up in the air; we haven't solved the issue of session management under Wayland either, and saving the state of the window could be seen as part of that. And no: doing what XSMP does is not a viable answer, since XSMP is not a sane protocol.
Hello, you have a "southern islands" based card, it does not yet support crossfire. You can see how driver support is in your card for AMD here
Your card is actually pretty decently supported, so if you'd like to try linux you can drop down to a single card configuration and give it a whirl.
>##Option "EmulateWheelButton" "integer"
>Specifies which button must be held down to enable wheel emulation mode. While this button is down, X and/or Y pointer movement will generate button press/release events as specified for the XAxisMapping and YAxisMapping settings. If the button is 0 and EmulateWheel is on, any motion of the device is converted into wheel events. Default: 4. Property: "Evdev Wheel Emulation Button".
You can also use xbindkeys to add binds that convert the emulated scrolling into arrow key keystrokes, which means you can use your trackpoint to whip around a text file too.
Oh, it's not just you. I can't find any consensus on boot options either.
Assuming Fedora, check: http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/ap-admin-options.html
Turns out that instead of “display” Fedora has (among others):
inst.resolution=- “Specifies the screen resolution in graphical mode. The format is NxM, where N is the screen width and M is the screen height (in pixels). The lowest supported resolution is 640x480.”
inst.xdriver=- “Specifies the name of the X driver to be used both during the installation and on the installed system.” ^((Probably “
radeon”, but I dunno.))
- “Specifies the name of the X driver to be used both during the installation and on the installed system.” ^((Probably “
inst.usefbx- “Tells the installer to use the frame buffer X driver instead of a hardware-specific driver. This option is equivalent to
inst.xdriver=fbdev.”
- “Tells the installer to use the frame buffer X driver instead of a hardware-specific driver. This option is equivalent to
And on this page, « http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/ch-Boot-x86.html#s2-x86-starting-bootopts », there's this:
>To pass options to the boot loader on an x86, AMD64, or Intel 64 system, press the «Esc» key at boot time. The boot: prompt appears, at which you can use the boot loader options described below.
And if you can manage to get the installer to install, this might be useful for configuring X.org: www.x.org/doc/radeon.4
Of course, I could be completely wrong about what the problem is. Caveat emptor.
I suspect though that Prime support in Nvidia driver and tools is improving, and at some point Optimus will be supported much better. It's mentioned briefly in the recent presentation about Wayland support: http://www.x.org/videos/XDC2014/RitgerEGLNonMesa.webm (See at 1:50).
> What exactly stops people from sponsoring internships for men in open source?
The fact that if someone were to create such a thing they would be attacked to no end for being a sexist misogynist pig and probably would be forced to end it.
> And it looks like X.org is doing that as well, see here: http://www.x.org/wiki/XorgEVoC/
So women have two opportunities while men only have one? That still hardly seems fair.
http://www.x.org/wiki/Development/Documentation/PointerAcceleration/
I use this:
Section "InputClass"
Identifier "generic mouse"
Option "AccelerationScheme" "none"
EndSection
nothing more is needed, if you only want to disable acceleration and it is the most accurate mouse which you can get
They have plans and ideas. There's been talk about them using KMS upstream, or inventing a new API for us to use in EGL somewhere. Red Hat's X team has been talking with NVIDIA about how to do this, but there hasn't been any real conclusion from what I can tell.
The most recent thing I've heard is James Jones talking about putting "A new modesetting API!?!?" in EGL on page 6 of these slides.
Try using synclient (should have been installed with X) and see if you can change the settings using that. It's a command line app.
Start by checking what the settings currently are: synclient -l
For example turning on Two Finger Scrolling looks like: synclient VertTwoFingerScroll=1
I try to help too (if only to support my 7850 card better) but the whole stack is excruciatingly complex and hacking it needs a lot of domain expertise. Phoronix is a good resource, especially the forums. Several developers hang out there. Also xorg and freedesktop IRC (#radeon and #dri-devel on freenode, maybe #xorg-devel.)
Good bug reports at https://bugs.freedesktop.org are crucial. http://www.x.org/wiki/RadeonFeature/ is a good starting point. Mesa/drm happens at freedesktop.org (http://freedesktop.org/wiki). I'd start with hand building the DDX and libdrm if you want to hack. Oh and glamor-egl of course, that's a big one.
> Wayland is a experimental tech demo right now. It is not the future of Linux at the moment.
X being fast is less a matter of design superiority, and more a matter of "lack of competition made it a highly polished turd." That's probably overstating X's problems, but it's still an incredibly crufty protocol and codebase built on hacks built on hacks, and is pretty much locked into that state of being for backwards compatibility. On most systems, from low-end to high-end, Wayland will be a much faster graphics pipeline, though it has a long way to go in terms of maturity.
I don't mean to pretend that Wayland is without its own inherent issues - leaving window decorations up to clients, for example, is gonna be a pain in everybody's ass. But that doesn't mean it's worse than X, merely an "experimental tech demo," or doomed to failure as the future of efficient Linux graphical stacks. And you don't need to be high on buzzwords and blogspam to see that - all you need are a bit of patience and pragmatism.
XRender is a little more than simple compositing. It provides a single rendering operation which can be used in a variety of ways to generate images: dest = (source IN mask) OP dest Where 'IN' is the Porter/Duff operator (http://www.x.org/releases/current/doc/renderproto/renderproto.txt). Porter/Duff is all about alpha channel compositing images.
Most programs don't care about X server rendering API because they use toolkits. But you still can run X on wayland so if wayland will take over the world users will not be left with broken programs.
This is a guess but I just had to do some playing with xorg the other day configuring my resolution and I learned a lot.
I presume your mouse driver is controlled by X's evdev driver. It looks like you can change the calibration based on this doc:
http://www.x.org/archive/X11R7.5/doc/man/man4/evdev.4.html
So create a file called 20-mouse_calibration.conf in /etc/X11.xorg.conf.d/ and put something like this in it:
Section "InputClass" Identifier "mouse calibration" MatchIsPointer "on" MatchDevicePath "/dev/input/event*" Driver "evdev" Option "Calibration" "min-x max-x min-y max-y" EndSection
Start putting in values for min-x, max-x, min-y, and max-y. I think that will work. I won't bother to look up if you can tell xorg or evdev to reconfigure itself without restarting, though. :)
> I want a SWE job, but (as you can see) my experience is very limited.
Most big companies (esp. those you mentioned, who may have a need for smart generalists) have a separate hiring process for recent college grads. Check out the job fairs in either one of your colleges, and talk to your career services department to see if they have a job listings site where the companies are looking for entry level grads. Also see if there are any on campus interviews going on. As an aside, if you can manage to get an interview with them, I hear that Google likes to ask Discrete Math and algorithm questions.
> I don't have experience to put on there so I put those on there. I figure for entry level jobs, this is the norm?
Yeah, you can pad, but most job hunting sites tell you to keep your resume down to a page for a reason. Your resume is a document to sell you, not a complete biography. That just seemed like something superfluous to axe.
>> volunteering for a open source project
> Where do I start with this?
You're asking for a software engineering job, but that covers a hell of a lot of ground. It helps to distinguish you if you have demonstrable evidence that you like the specific kind of work that a company is going to hire you for. Did you enjoy your systems programming classes? Find an obscure piece of hardware and write a Linux kernel driver for it. Want to put all that discrete math to use doing something related? Try fixing some issues with the radeon driver. (Or, hell, play around with the Facebook puzzle page). Enjoyed your programming language theory classes? Hop on the IRC channel of any major interpreter (Python/Ruby/PHP) and see if you can start with something small, like increasing the coverage of their unit tests. Nothing says you know the library of a language by finding new bugs in it.
Agreed. The nouveau driver is a long way behind, and it suffers through having to do reverse engineering to get anywhere at all. It is, however, an open source driver, and hence it does support graphics memory management and KMS in the kernel, unlike the proprietary binary blob nvidia driver.
The open source drivers from Intel and AMD likewise support these functions in the kernel
Look here down the page under the heading "Feature dependency tree": http://www.x.org/wiki/RadeonFeature
KMS, DRI2/RDR and advanced 3D (OpenGL 1.5+) depend on the memory manager. Advanced power management, run X without root privileges and Wayland depend on KMS. Flicker-free 3D with compositing and Gallium 3D depends on DRI2/RDR, while OpenCL and video decode acceleration depend on Gallium3D.
Every single buzzword in the above paragraph depends on the graphics memory manager being in the kernel. That won't happen with a binary blob proprietary driver.
Ergo, the entire future of the graphics stack in Linux depends on not running a closed source binary blob graphics driver.
Apparently this truth is a little too difficult for sensitive Redittors, and my earlier post pointing out this fact has been down-voted three times despite being the truth. What was that old saying about "don't shoot the messenger"?
> As I said above, the Intel open-source drivers have the best support for kernel features like KMS, suspend
According to x.org suspend isn't yet supported.
Neither is multiple monitors (which I care less about).
And so many apt dependencies in ubuntu and ubuntu based distros.. Installing a list of programs in the wrong order might give you too many programs.
It's due to the Task dependency and you can't disable it without removing needed dependencies.
----
More on this if you do "apt show xorg":
Depends: xserver-xorg (>= 1:7.7+19ubuntu14), libgl1-mesa-glx, xfonts-base (>= 1:1.0.0-1), x11-apps, x11-session-utils, x11-utils, x11-xkb-utils, x11-xserver-utils, xauth, xinit, xfonts-utils, xkb-data, xorg-docs-core, gnome-terminal | xterm | x-terminal-emulator, xinput Recommends: xfonts-scalable (>= 1:1.0.0-1) Suggests: xorg-docs, xfonts-100dpi (>= 1:1.0.0-1), xfonts-75dpi (>= 1:1.0.0-1), x11-xfs-utils Homepage: http://www.x.org/ Task: ubuntu-desktop-minimal, ubuntu-desktop, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop Download-Size: 3060 B
Or use arandr https://christian.amsuess.com/tools/arandr/
“ARandR is designed to provide a simple visual front end for XRandR. Relative monitor positions are shown graphically and can be changed in a drag-and-drop way.”
Mhh...good question. Theoretically it shouldn't be hard to do...but I am not aware if there is a program doing it. The "garbage" is easy as said...start to program you used to setup the screen and move the right screen up that is doesn't overlap the left one at the bottom anymore. The right garbage...mhh...you can try something like xsetroot to set a constant background colour...maybe that fill the non-visible parts too.
My 290 works beautifully, though HD7770 appears to be Southern Islands, while 290 is Sea Islands, (from the "Decoder ring for engineering vs marketing names" section) so it makes sense they'd work differently.
<code>xset</code> might be what you're looking for if you're using Xorg. xset -q displays current settings, and the bottom line shows whether the monitor is on (which I assume would change if it's in standby or off as well). xset s 600 600 sets the timeout (in seconds) and the cycle for the standby.
If you're only using a tty you might want to use <code>setterm</code> with flags like -blank [0-60] and -powerdown [0-60] (parameter in minutes).
You might want to try writing an xorg.conf, where you can certainly do this type of thing. Look at the 'Virtual', 'ViewPort', and other Display options.
don't start the nonsense petty arguments, please
(like "JS over dbus"... ofc JS is not sent over dbus... jesus christ)
i don't feel like arguing today so here's a knowledge dump
http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#Protocol_Formats
is how a protocol looks like (as in over-the-wire, as in not dbus)
https://en.wikipedia.org/wiki/Attribute%E2%80%93value_pair
key value pair (as in not XML nor INI)
as for a programming language, there is no need for a turing complete language in the case of
"compositor wants to know if this program is allowed to do this thing"
http://www.thomasstover.com/uds.html UDS gives the program the pid of the other program
(as well as the user id and such, man credentials)
so a daemon running with privileges can check anything about the running program (pid, sent by the registered compositor)
edit:
3min downvote
you are petty, i see
The X server itself doesn't support hardware accelerated rendering of the desktop, so without a compositor, it's really rendering the entire desktop in software. This is not a good thing for performance (of course on high-end PCs you might not notice it, but on e.g. a Raspberry Pi the X desktop is very noticeably slow). Support for compositors was then added as an afterthought to the X architecture. A compositor does the rendering of the screen image using hardware accelerated graphics (typically OpenGL) on behalf of the X server, which reduces CPU load since there's no software rendering going on, and is generally just a good idea since every computer (excluding servers with e.g. Xeons) today has at least a built-in GPU that is capable enough for compositing, and that will only sit there unused if you use software rendering for drawing the desktop. It also reduces things like flickering, flashing and tearing on the desktop. And there are systems on which it does make a difference right away: on a Raspberry Pi, the WIP Wayland-based Maynard desktop is noticeably much smoother and faster than the default LXDE desktop.
Note that desktop effects such as the ones in KWin and Compiz are not compositing, they're just one of the nice extra things that become possible when the desktop compositing is done in hardware on a GPU. Running a compositor such as compton or xcompmgr gives an advantage even if you aren't using any effects such as drop shadows or transparency.
Wayland solves problems in the X architecture, protocol and server. Here are two good articles about what's good and bad about X, and how Wayland is different:
Never say never: http://www.x.org/releases/X11R7.6/doc/xextproto/security.html
It was actually used in the Nokia N9 to some extent (in collaboration with its Aegis security framework), but that's the only place anyone I've heard anyone has ever used it. Because, you know, nobody really cares, because people seem to so rarely run malware on Linux.
I'm certain if people cared enough, they would be able to implement it for Xorg, as it's been designed already. But the actual reality is that people like to have screenshot applications more than security, so now we have nice and practical screenshot applications. And I don't mind.
It does now only due to lack of time to implement it, it will feature configurable acceleration and sensitivity based on mouse DPI (if you desire):
http://www.x.org/wiki/Events/XDC2015/Program/hutterer_libinput.html#slide11
> "Typical video display circuits generate vertical blanking and vertical sync' pulses when the display picture has completed and the raster is being returned to the start of the display."
The "video display circuit" in question is the video card's scanout hardware. The Xorg project has decent documentation here.
>I actually have a second 7970, will crossfire ever get supported by non-proprietary drivers?
Yes. It's on the feature todo list as shown here (third from the bottom, but that list isn't sorted so I don't actually know what the priorities are).
That said, driver devs are probably better off working on single-card performance than on implementing Crossfire support, because with OpenGL the gains are relatively meagre due to the API not parallelising well. Multi-GPU will be much better handled by Vulkan, which will require a separate driver IIRC.
They are not overlapping, there isn't much to mess up with the tool, you can drag the screens where they are in relation to each other, set their resolution/orientation, outside of that you can't really configure anything else. take a look at the xrandr man page there are a lot of other options for positioning of the screen that the tool does not handle.
This fix might work for your situation.
What desktop environments are you using? Maybe try something basic like lxde or openbox and see if CPU usage goes down.
Edit: you might also find other options to play with in the xorg-mga man page here: http://www.x.org/archive/X11R7.5/doc/man/man4/mga.4.html
When your controller was plugged in, was there a line in the output of dmesg beginning with input:?
Making up an example for lack of an Xbox controller on this end. Say the input: line had this:
[ 2425.596179] input: Microsoft Gamepad for Xbox 360 as /devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11:1.0/bluetooth/hci0/hci0:256/0005:057E:0330.0002/input/input17
With the above sample output, I would try changing the MatchProduct directive in my example to Microsoft Gamepad. The first un-commented section in my example is probably the main one to look at.
Section "InputClass" Identifier "Xbox Raw Input Blacklist" MatchProduct "Microsoft Gamepad" MatchDevicePath "/dev/input/event*" Option "Ignore" "on" EndSection
Some of the X documentation (Link) says that MatchProduct matches any substring, not just "starting with", so putting in "Xbox 360" could alternately work just as well.
There's a huge number of configuration options, so you may have to do a fair bit of experimentation to find the combination that's best for you. And that's assuming that xorg.conf files are still relevant. Re: www.x.org/archive/X11R7.5/doc/man/man4/synaptics.4.
Pretty sure you can not have catalyst libGL and mesa libGL installed at the same time. That's the big pain point with the current OpenGL ABI that games call /usr/lib/libGL.so which is the vendor specific implementation. That's why NVIDIA proposed a new OpenGL ABI and a vendor neutral dispatch lib. https://github.com/NVIDIA/libglvnd
Maybe with a script that does some symlinking magic before switching that would work but I'm not sure.
If you have man pages installed, man xeyes should give you something similiar to this: http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html
The document covers changing the window size, but I don't know off the top of my head how to change window position. I'd assume you'd more likely do that through some X function than the xeyes program itself.
This may or may not be related. It solved many of my issues.
http://www.x.org/wiki/radeonBuildHowTo/
> apt-get update
> apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri <--- libGL.so + mesa3d DRI drivers
>WARNING: The proprietary drivers from AMD/ATI and nVidia are known to overwrite Xserver extensions, for example GLX extension (libglx.so)!
I personally have glx errors when failing to launch portal 2. So I'm sorta in the same boat.
Was considering moving to the latest open source drivers.
http://www.x.org/wiki/radeonBuildHowTo/
> apt-get update
> apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri <--- libGL.so + mesa3d DRI drivers
>WARNING: The proprietary drivers from AMD/ATI and nVidia are known to overwrite Xserver extensions, for example GLX extension (libglx.so)!
I did this. Steam works again. Sorry for bothering everyone!
There's X.org. It's used on some server distros.
Edit: Listen to /u/BCMM I don't deal with X11 much other than just knowing it's there so I guess I was making some really old assumptions.
Also, to get an overview for configuration, the support for the RV620 chipset in the radeon driver which you use currently is not that bad. Here is the overview of the supported features.
If you enable KMS and direct rendering there is quite a chance that you achieve better performance in 2D than using the proprietary drivers.
You can also use the sgfxi installation script with the option -n at lauch to update it to the latest revision. It should also fetch the latest libmesa. And configure your xorg.conf accordingly.
You might want to look into XSendEvent and XTestFakeKeyEvent. I'd expect there to be python bindings for xlib stuff but if not at least I didn't find writing C for this to be too frustrating, however I did have problems with both functions occasionally not performing as expected.
If you go this route you have a good chunk of documentation to wade through. Fortunately at least for xsendevent the documentation isn't too bad, though you'll have to figure out the required structs, which means more documentation reading.
If you go the xfakekeyevent route, this will require you to use the xtest extension to x11, but I can't imagine running in to problems while using dwm. iirc you'd just need a compiler flag or something of that sort. I remember the documentation for xtest stuff being hard to find, so here's the link I used.
If none of this works for you and you're confident in your C abilities, you could look for something in dwm's source code. The main file is ~2kloc and I found it more readable than I expected a wm to be.
Have you ever tried using a tiling WM then? a really minimal one I know of is ratpoison. When there's no applications running all you see is your X cursor and the Xorg root background colour (usually black, but I think there's a command to change that).
EDIT: I found this here, it's xsetroot -solid <colour>