Thank you for doing that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1327801
Title:
Bightness and contrast settings have no effect
To manage notifications about this bug go to:
Ideally, whoever wrote the original patch would be involved, because I
assume his gamma fix was pertinent to some piece of hardware available
to him, just happened to break the Canon LiDE scanners.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Just looking at the log, it seems that unused-parameter error is
enabled. I don't know how your pipeline works, but it's not dpkg-
buildpackage, so it makes sense that the default CFLAGS (or CXXFLAGS) is
set.
genesys/low.cpp:636:76: error: unused parameter 'sensor' [-Werror
=unused-parameter]
Sure, I used `dpkg-buildpackage -b``` to build it.
The change was just to remove the offending condition as was suggested:
diff -ur sane-backends-1.0.29.orig/backend/genesys/low.cpp
sane-backends-1.0.29/backend/genesys/low.cpp
--- sane-backends-1.0.29.orig/backend/genesys/low.cpp 2021-02-16
Hi Gunnar,
Perhaps there is a mistake in that report. I certainly witnessed it in
1.0.29 on Ubuntu 20.04 and 20.10. I don't think it was an issue before
that version, and it's unlikely to have been, as the revision that broke
it was put in October 17, 2019; not certain about which specific
I have tracked the issue down to an upstream issue with sane-backends,
with a fix here:
https://gitlab.com/sane-project/backends/-/issues/271
This is not a simple-scan bug.
** Bug watch added: gitlab.com/sane-project/backends/-/issues #271
Here is some debug output when a scan is initiated.
The brightness and contrast values do seem to apply from the front-end:
[+16.68s] DEBUG: scanner.vala:1674: Scanner.scan
("genesys:libusb:001:010", dpi=600, scan_mode=ScanMode.GRAY, depth=2,
type=single, paper_width=2159, paper_height=2794,
Like Michael in #17, I noticed that since around 20.04 my Canon LiDE 35
has no brightness-contrast control, making simple-scan unusable for me.
I've worked around by using other software, but it's starting to bug me
as more stuff needs to be submitted online in today's world.
--
You received
Public bug reported:
32.0.0.465ubuntu0.20.04.2 removed Flash from my system!
It's not okay to remove plugins the user may be using without their
permission. I need this plugin for work, and now I can't find a good way
to reinstall it.
** Affects: flashplugin-nonfree (Ubuntu)
Importance:
I can't speak for 3D, but seeing as the 2D rendering is still loads
quicker than canvas, the "performance caveat" really isn't.
What should PIXI, or any site, do with this information?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
(In reply to Jeff Gilbert [:jgilbert] from comment #24)
> (In reply to Pat Suwalski from comment #20)
> > (In reply to Jeff Gilbert [:jgilbert] from comment #19)
> > > Honestly at this point I'm tending towards #2.
> > > Websites had the chance to handle this well a
(In reply to Jeff Gilbert [:jgilbert] from comment #19)
> Honestly at this point I'm tending towards #2.
> Websites had the chance to handle this well and they have bungled it, so I
> think we should disable failIfMajorPerformanceCaveat as it stands today.
Are you suggesting PIXI doesn't handle
Although Firefox 84b2 from official binaries worked fine, Firefox 84.0
from official binaries (firefox-84.0.tar.bz2) does not.
Setting ```gfx.webrender.all``` as suggested above *does* work.
This appears to be a capability detection issue.
--
You received this bug notification because you are
Setting gfx.webrender.all as recommended in the upstream bug makes it
work. It seems some detection code is broken.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905054
Title:
Firefox 83 Breaks
Can anyone point me to where I can find the Firefox 82 debs? They seem
to have disappeared from /var/cache/apt/archives, and I really need
them.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905054
The Firefox 84 WebGL section looks a lot like the v83 section:
HW_COMPOSITING
available by default
blocked by env: Acceleration blocked by platform
OPENGL_COMPOSITING
unavailable by default: Hardware compositing is disabled
WEBRENDER
available by default
disabled by env: Not
Despite it working in The Firefox 84 beta, the Ubuntu build that came
out does not work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905054
Title:
Firefox 83 Breaks WebGL
To manage
Can you guys try the Firefox 84b2 build? I tried it from the tarball and
it worked perfectly.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905054
Title:
Firefox 83 Breaks WebGL
To manage
If I were to speculate, someone tried to fix the "blocked by env" errors
in Firefox 82, in the process actually making that statement true with
some kind of fail code. In 84 they may have actually fixed whatever the
root problem reporting that message.
--
You received this bug notification
I can verify that the beta snap works as well, but I thought you said in
comment #2 that is a binary build straight from mozilla.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905054
Title:
It's the "Acceleration blocked by platform" bits that are interesting.
It seems that message is there in v82 where it works and v83 where it
doesn't. The apparmor check seems relevant with that angle, I just want
to make sure that it's not something related to Ubuntu.
If it continues to work in
I just realized that the about:support output above is actually for
Firefox 82, which is odd, because it does work even though the output
suggests it shouldn't.
Here's a lot for Firefox 83.
The relevant section is different once again:
Decision Log
HW_COMPOSITING:
available by default
blocked
I just realized that the about:support output I supplied above is from
firefox 82. I am confused by the HW_COMPOSITING section, when it clearly
works in v82.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Indeed, I downloaded firefox-84.0b4.tar.bz2 and WebGL works correctly in
that build.
On 84, compared to 83 above:
Decision Log
HW_COMPOSITING
available by default
OPENGL_COMPOSITING
available by default
WEBRENDER
available by default
WEBRENDER_QUALIFIED
available by default
Here is the output of about:support. I suspect this is the relevant
part:
Decision Log
HW_COMPOSITING:
available by default
blocked by env: Acceleration blocked by platform
OPENGL_COMPOSITING:
unavailable by default: Hardware compositing is disabled
WEBRENDER:
opt-in by default: WebRender is an
Thanks for the ideas.
drm driver as listed from lsmod:
drm 491520 9 drm_kms_helper,i915
I tried the snap and it behaved the same way, the exact same console
output. The snap was version 83.0-2 via snapcraft.io.
I assume by "xrg" you mean "xorg"? I have not tried under an xorg
Public bug reported:
Upon upgrading from Firefox 82 to to Firefox 83, WebGL stops working.
Ubuntu 20.10 with Wayland.
When I try to launch a webGL game:
Failed to create WebGL context: failIfMajorPerformanceCaveat: Compositor is not
hardware-accelerated.
Specifically Pixi says:
Error: WebGL
In its settings:
intl.locale.matchOS: true
intl.regional_prefs.use_os_locales: true
** Summary changed:
- thunderbird 1:52.9.1+build3-0ubuntu0.18.04.1 1:60.2.1+build1-0ubuntu0.18.04.2
breaks timezone preference
+ thunderbird 1:52.9.1+build3-0ubuntu0.18.04.1 1:60.2.1+build1-0ubuntu0.18.04.2
Public bug reported:
The latest security update of thunderbird
1:52.9.1+build3-0ubuntu0.18.04.1 1:60.2.1+build1-0ubuntu0.18.04.2
(upgraded 2018-10-17) breaks time format.
pats@palladium:~$ locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC=en_CA.UTF-8
LC_TIME=en_CA.UTF-8
Good find, #6. I came about the same result but couldn't explain why my
control center stopped crashing.
I needed to make some online account changes, so I had switched to the
Ubuntu session to get that done, and the control center worked
flawlessly in Gnome ever since. Your explanation seems
I have this error occurring when I run the regular GNOME session.
In Ubuntu session, control panel works. In GNOME session, settings does
not launch. Launching "gnome-control-center" from terminal provides the
core dump message initially reported.
--
You received this bug notification because
Turns out this is an ibus bug. Right-clicking on input field and
selecting Input Method-Simple fixes the issue, using the proper Gtk
mapping.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1163023
** Branch linked: lp:~ubuntu-desktop/gtk/ubuntugtk3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1163023
Title:
GTK Compose Behaviour for ć Incorrect
To manage notifications about this bug go to:
Public bug reported:
According to the GtkComposeTable:
https://help.ubuntu.com/community/GtkComposeTable
ćcapostrophe0107small C with acute
This behaviour, and its capital version do not work. They instead
produce ç and upper-case variant.
Tested on 12.10 and 13.04 from March
Public bug reported:
Starting with Ubuntu 12.04 and still in 12.10, Compose+'+c is producing
ç rather than the expected ć.
This is throughout the various toolkits. Locale is set to en_CA.UTF-8,
which should derive the compose settings from en_US.UTF-8. Keyboard
layout is us.
ProblemType: Bug
I had this happen, and I narrowed it down to mounted media. Unmounting
the DVD first (umount /dev/dvd1 in my case) then made dvdbackup behave
correctly.
--
dvdbackup crashed with SIGSEGV in DVDClose()
https://bugs.launchpad.net/bugs/450342
You received this bug notification because you are a
Indeed, it would be nice to have the old behaviour back. The new
behaviour is inconsistent and hard to use.
--
Rhythmbox notification icon click hide/show
https://bugs.launchpad.net/bugs/525875
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Looks like it's been solved one way or another.
AccelMethod XAA no longer seems to do anything. Whether it's there or
not, this is in the Xorg.log:
(II) RADEON(0): EXA: Driver will not allow EXA pixmaps in VRAM
(...)
(II) RADEON(0): Setting EXA maxPitchBytes
(II) EXA(0): Driver allocated
Indeed, I grabbed the karmic build from 20090902, ran it as a live CD.
This didn't have an xorg.conf, and the generated Xorg.0.log indicates
that XAA was loaded automatically in lieu of EXA.
I then proceeded to try Firefox, but it crashes on startup, probably
because the window is quite large and
Indeed, switching to XAA seems snappier than EXA. I hadn't noticed the
change because I was using a custom xorg.conf file around the time when
EXA became the default.
I'm not sure there's much point in trying with EXA again in Karmic,
assuming that EXA is still default and will still be slow.
lspci -vvnn.
** Attachment added: lspci.txt
http://launchpadlibrarian.net/28950262/lspci.txt
--
32MB r200 DRI Slow - Fails to allocate texture
https://bugs.launchpad.net/bugs/394402
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Xorg.0.log; xorg.conf not modified.
** Attachment added: Xorg.0.log
http://launchpadlibrarian.net/28950277/Xorg.0.log
--
32MB r200 DRI Slow - Fails to allocate texture
https://bugs.launchpad.net/bugs/394402
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Public bug reported:
I have a Dell Inspiron 600m with a 32MB Radeon 9000m, which uses r200
DRI. It has a 1400x1050 display, which with that little video RAM means
I always disable compiz, and use metacity instead.
As of 9.04, the DRI has gotten very slow. Switching tabs in Firefox can
take up to
I just released a new version of evolution-scalix that is Evolution
2.22-compatible. Please see:
ftp://ftp.gnome.org/pub/gnome/sources/evolution-scalix/11.4/
The only strange thing is that I have to clear LDFLAGS to have the
plugin load properly in Evolution. Hardy's dpkg-buildpackage puts some
44 matches
Mail list logo