Re: t460s fedora 24 - display freeze
On Tue, Sep 20, 2016 at 12:30 PM, Dusty Mabe wrote: > > Several times over the past month my t460s has just blank screens > when I come back to it after some time. I don't know if the thing > froze up completely or if it is just the display not working. I lock > my screens (laptop + 2 external monitors) and then leave for an hour > or so. When I come back no attempt at input will get the lockscreen > to appear. I have to power down and then back up. > > After boot I look at the journal and I always tend to see some of > these: > > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO > underrun > [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe C > (start=167156 end=167157) time 146 us, min 1073, max 1079, scanline start > 1072, end 1082 > [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A > (start=488827 end=488828) time 107 us, min 1073, max 1079, scanline start > 1072, end 1080 > > I'm not saying these are what is causing the issue but are at least > something I noticed. > > I'll continue to monitor this problem. It only happens like once every > two weeks so it is hard to prepare for it by knowing the IP address so > that I can try to ssh in to see if the system is frozen or if it is > just the screen. > > Has anyone else seen some behavior like this? I am using i3wm and my > system is updated approximately once a week, so I should have close to > the latest software installed. > > Thanks, > Dusty > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > I ran in to a problem that involved an unresponsive screen a few months ago and also had a FIFO underrun. I think your problem is somewhere in the intel graphics stack. Here's the bug I had: https://bugzilla.redhat.com/show_bug.cgi?id=1339855 https://bugs.freedesktop.org/show_bug.cgi?id=96284 I was able to determine the system wasn't frozen because I made a unit file that ran a bash script that saved a file on shut down and then pressed my power button. Systemd ran the script and I was able to see the file had been updated. The fact that it was able to shutdown without me forcing it was also a good sign that this was the case. Some info about reporting these bugs is here: https://01.org/linuxgraphics/documentation/how-report-bugs If you want to try some drivers that are close to the developer version upstream you can try my copr repo: https://copr.fedorainfracloud.org/coprs/bollocks/intelblood/packages/ It hasn't been updated in a month. I'm going to get on that today. I try for once a week but since I no longer have any bugs I don't run it on my machine and so I forget easily. Note that running these is probably crazy experimental and the package maintainer(me) is far from an expert. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, Dec 15, 2016 at 6:08 AM, Kamil Paral wrote: > > Now that Fedora 25 is out of the door, I'd like to start a discussion > about > > the future of officially-supported (meaning rigorously tested) optical > media > > for future Fedora releases. > > The discussion died off, so let me summarize and propose a plan. > > We haven't received as much feedback as I hoped for. Maybe people don't > care enough about optical disks to even respond, or it might be a different > reason. But we also didn't receive as much negative feedback as I feared. > So hopefully this does not negatively impact too many people. The comments > under the Phoronix article [1] weren't too helpful either, a few rants but > no-one cared to follow up with some explanation or system specification > which would be negatively affected for his/her use case. Some of them, I > believe, just read the article title without realizing this only affects > Alpha/Beta media or certain flavors of Final media. > > [1] http://phoronix.com/scan.php?page=news_item&px=Fedora-Post- > 25-Optical-Future > > > > Idea #1: Do not block on optical media issues for Alpha and Beta releases > > > ~ > > This is the less controversial idea, I believe. We received a concern from > Matthew, who was worried that we might find out too late if we don't check > it for Alpha/Beta. I partly agree, but believe we should solve it with an > improved QA processes, instead of bumping the release criteria to apply > earlier. He did not object to this, and nobody else did, so I assume > everyone agrees :-) If there are no further concerns, I'll prepare a > criterion adjustment proposal for this. > > > > > Idea #2: Do not block on optical media issues for Final release for > certain > > flavors/image types (Server, netinst) > > > ~ > > > > This is a bolder variant of the previous idea and can be done separately > or > > combined with it. It makes optical media functionality not guaranteed > even > > for Final release, but just for certain Fedora flavors or image types for > > which it makes sense (not all of them). Which images to cover, that's the > > heart of the discussion. If you look into our test matrix again, we > > currently block on 6 of them: > > * Workstation Live + netinst > > * KDE Live > > * Server DVD + netinst > > * Everything netinst > > This was received with reasonably positive reception as well. But it's > harder to compile a list which images should be covered by criteria and > which not. > - Workstation Live will be covered, that's clear - we give out these DVDs > at events, it's sent out to the developing world > - Everything netinst is the most universal and generic netinst, so > covering that one means we don't need to cover Workstation netinst and > Server netinst. People seem to agree to this. > - Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs. > If we cover Workstation Live, it's improbable that only KDE Live would > break, but not impossible. If such thing happens, are people OK with > releasing Fedora XX KDE Live only bootable over USB? > - Server DVD is a mixed bag. Matthew didn't include it in his block-list, > Adam did. Neal uses it over IMPI (but netinst would be good enough for him > IIUIC, sans some package deps issue which can be solved using a kickstart). > I would appreciate more feedback from Server folks. Again, we'll cover > netinst so it's improbable DVD would break, but not impossible. Are people > OK releasing it only bootable over USB (and PXE)? > > Thanks. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >We haven't received as much feedback as I hoped for. Maybe people don't care enough about optical disks to even respond, or it might be a different reason. I must have missed this and deleted it by mistake. I had something weird happen when F23 was the latest release. Somehow, probably through user error, I deleted my partition table and bricked my only USB stick. I think I corrupted the USB stick firmware somehow. I have only one computer so using another to get another copy wasn't an option. I did have a back up Fedora DVD because an earlier experience in life when I found myself without an OS and a broken installation. I think that having a read only media option with physical damage as the only failure mode is valuable. I continue to keep a Fedora DVD even though I prefer installing through USB. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New pastebin service on paste.fedoraproject.org
I only get 21 lines. I'm know nothing about web page design and even less about image editing as you'll see but the attached pic seems like what I would do placement wise. Does it give away too much horizontal space for vertical screen users? Could it detect orientation and choose this one for horizontal only? On Thu, Feb 23, 2017 at 11:20 AM, Kevin Fenzi wrote: > On Thu, 23 Feb 2017 16:47:45 + > Richard Hughes wrote: > > > I'm not sure if this is the right mailing list for this issue. > > Probibly not. The infrastructure one would be better, but oh well. > > > Basically, the paste.fedoraproject.org site has been recently changed, > > and it's basically useless for me now. This screenshot shows the > > issue: > > https://people.freedesktop.org/~hughsient/temp/ > Screenshot%20from%202017-02-23%2016-38-52.png > > > > My frustration is that with all the beautifully designed CSS and > > padded chrome around everything we can only fit 22 lines of actual > > text on the screen. That's about half of the lines that I can get when > > using http://pastebin.com and a third of what I can get with > > https://paste.opensuse.org. > > So, some of that could be our theme, which is already being discussed > at: > https://pagure.io/fedora-infrastructure/issue/5816 > You could chime in there and see if things could be made more compact. > > Or it could be an upstream issue (yea for having an upstream again!): > Looking at their demo site: > https://demo.modernpaste.com/ > it does seem the layout is pretty set. So, perhaps you could ask them > to make things more compact there? > https://github.com/LINKIWI/modern-paste/issues > > The paste URLs from the latter are also > > https://paste.opensuse.org/53391866 (35 chars) compared to > > https://paste.fedoraproject.org/paste/3epoM9U0i4oKyPlw7Z6nfl5M1UNdIG > YhyRLivL9gydE= > > (82 chars) > > If you use the command line 'fpaste' util it gives you a shortened url. > We have been discussing how to also include that in the web side. > > > > I find myself no longer using paste.fedoraproject.org -- it can't just > > be me being a grumpy old man, can it? Am I holding it wrong? > > Well, it's change and everyone dislikes that. I hope we can convince > upstream to make changes that our users (like yourself) wish so it's > nice for everyone. > > kevin > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Touchpad pointer accel - testers required, scratch build available
I think I sent you some touchpad data before for a Toshiba Tecra M11. I have xorg-x11-drv-synaptics installed to keep my setup from F24. Do I need to do anything besides get rid of /etc/X11/xorg.conf.d/50-synaptics.conf and restart X to make this work right? On Thu, Feb 23, 2017 at 5:35 PM, Peter Hutterer wrote: > I've been playing with touchpad pointer acceleration in libinput again and > finally found something I'm happy with. Most notably it has a wide range of > configurable speed settings, from "tar" to "speed-skating ring". Please > give > this scratch build a test and let me know how you go: > https://koji.fedoraproject.org/koji/taskinfo?taskID=17546245 > > Reminder: after installing you *must* log out of X/Wayland for the changes > to take effect. > > Thanks > > Cheers, >Peter > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Touchpad pointer accel - testers required, scratch build available
On Thu, Feb 23, 2017 at 8:26 PM, Peter Hutterer wrote: > On Thu, Feb 23, 2017 at 06:48:11PM -0600, Keith Keith wrote: >> I think I sent you some touchpad data before for a Toshiba Tecra M11. I >> have xorg-x11-drv-synaptics installed to keep my setup from F24. Do I need >> to do anything besides get rid of /etc/X11/xorg.conf.d/50-synaptics.conf >> and restart X to make this work right? > > yeah, that's all that should be needed. You can easily verify by running > xinput list-props "device name" afterwards and checking for the "libinput" > prefix on the properties. > > Cheers, >Peter > I've played with the . I'm using F25 LXDE spin. I saw all the rpms were named F26 so I rebuilt it from the srpm just in case. Here's what I've noticed. LXDE has a mouse and keyboard setting program built in but it has no effect with libinput. I used synclient with synaptics because there's not a lot of control in LXDE's mouse settings anyway. I've attached what libinput set as my defaults. It's the output from xinput list-props. I looked around and found an article in Arch's wiki that mentioned using xinput set-prop. I used xinput set-prop 13 --type=float 'libinput Accel Speed' to make the cursor move faster. 0 was way slower. I got all the way up to 1 and couldn't increase it further. The manual says that's what's supposed to happen so that's good.. It's fast enough that I won't revert right back to synaptics. It's not as fast as I'd like. I have a 1600x900 display and moving my finger slow so the acceleration doesn't kick in gets me about 7/8 of the way across the screen when I move all the way across the entire trackpad horizontally. I like to set it so 1/2-1/3 of the trackpad corresponds to corresponds to my entire screen when unaccelerated. I suggest making the maximum setting at least 6 times faster when unaccelerated. I'd probably set it 3 times faster. I tried -1 out of curiosity. That's not tar that's glacier lol. Accleration feels nice. I'm pretty happy with it. It kicks in a little to easily for me. Is there a setting I can mess with to customize this? I'm planning on leaving this as my driver for while so I'll get a better idea how it feels to use over time. The right portion of my trackpad is used for vertical scrolling. Libinput seems to recognize a smaller section as scrolling input than synaptics did. Synaptics default was really good for me. I don't see anywhere to change this. Is there a way? The current setting isn't bad and I suspect my muscle memory will adapt. This might have something to do with that problem we noticed with what my devices resolution was reported as and how far I could actually get it to say my finger was when I ran my finger around the edges of the pad. I don't remember numbers but it was pretty bad. There's no momentum in scrolling which is something I miss. In synaptics if I let my finger off the pad with more than a certain threshold for finger velocity it would keep scrolling and slowly reduce scroll speed to 0. It felt like a trackball. I tried out xinput set-prop 13 'libinput Tapping Enabled' 1 I normally don't use this but rarely I do. I have to hit it harder than I'd like to register a click. I'd like a setting to lighten it. Double tap and hold to drag seemed to require me hitting it way harder. I like requiring a harder hit for this to sort of act as a switch debouncer to determine if the user really meant a double tap or if their finger pressure just varied. It's way too high in my opinion. I'd suggest knocking 10-15% off of how hard you have to tap for a click. Then make double tapping as hard as regular tapping is now. If any of these suggestions have a setting I'd really like to know. Everything I know about what settings choices I have comes from man 4 libinput and https://wiki.archlinux.org/index.php/Libinput How does the calibration matrix work? The man page seems to assume you know what it is and how it works and just tells you how to specify it. -Keith libinputdefaults.tar.xz Description: application/xz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
