7:55 a.m.
Hi
https://launchpad.net/x-kit - DontZap is an application written in
Python which relies on X-Kit and allows users to set the "DontZap"
option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
Rahul
10 a.m.
Rahul Sundaram (sundaram(a)fedoraproject.org) said:
https://launchpad.net/x-kit - DontZap is an application written in
Python which relies on X-Kit and allows users to set the "DontZap"
option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
An app, a configuration framework with four differnet programs, all
to twiddle one configuration line. Impressive.
(FWIW, pyxf86config already exists in Fedora.)
Bill
1:15 p.m.
On Tuesday 31 March 2009 11:00:21 Bill Nottingham wrote:
Rahul Sundaram (sundaram(a)fedoraproject.org) said:
> https://launchpad.net/x-kit - DontZap is an application written in
> Python which relies on X-Kit and allows users to set the "DontZap"
> option in xorg.conf. Anyone interested in packaging this?
>
> You will need to package both x-kit and dontzap.
An app, a configuration framework with four differnet programs, all
to twiddle one configuration line. Impressive.
See, Ubuntu *does* contribute code back to the community!
--
Jarod Wilson
jarod(a)redhat.com
1:55 p.m.
New subject: dontzap - a application to revert dontzap setting
Yeah, I'll sure to file that in my "this_is_worthless" mercurial branch.
This change will simply require a very small edit to a kickstart file,
as I've attempted to explain to those in the C-A-Bsp thread.
-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
3:02 p.m.
New subject: dontzap - a application to revert dontzap setting
On 03/31/2009 11:55 AM, Adam Miller wrote:
Yeah, I'll sure to file that in my "this_is_worthless"
mercurial branch.
This change will simply require a very small edit to a kickstart file,
as I've attempted to explain to those in the C-A-Bsp thread.
FWIW, this will prolly get it done:
%post
grep -q -s DontZap /etc/X11/xorg.conf
append=$?
if [ $append -ne 0 ]; then
cat >> /etc/X11/xorg.conf << EOF
Section "ServerFlags"
Option "DontZap" "false"
EndSection
EOF
fi
%end
Can we all go home now?
2:43 p.m.
On Tue, Mar 31, 2009 at 11:00:21AM -0400, Bill Nottingham wrote:
Rahul Sundaram (sundaram(a)fedoraproject.org) said:
> https://launchpad.net/x-kit - DontZap is an application written in
> Python which relies on X-Kit and allows users to set the "DontZap"
> option in xorg.conf. Anyone interested in packaging this?
>
> You will need to package both x-kit and dontzap.
An app, a configuration framework with four differnet programs, all
to twiddle one configuration line. Impressive.
And all of this for manipulating xorg.conf, which doesn't even exists
on modern distros.
--
Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg(a)chrome.pl an IP-routable hand grenade.'' -- Andrew Morton
(LKML)
2:56 p.m.
On Tue, 2009-03-31 at 21:43 +0200, Tomasz Torcz wrote:
> An app, a configuration framework with four differnet programs,
all
> to twiddle one configuration line. Impressive.
And all of this for manipulating xorg.conf, which doesn't even exists
on modern distros.
Doesn't even exist *by default*. This is perfectly normal for
configuration files in many applications, it's a relatively common
system to have the file not exist by default and only need to be created
manually or automatically if a default setting is required to be
changed.
This doesn't make xorg.conf any less 'current' or 'valid'. It's
still
entirely supported by the X.org project and the only recommended /
supported / possible way to change certain configurations. The only
change from 'olden days' is that X is expected and configured to work
without it being present by default, as long as you don't want to change
any default settings.
I think people over-emphasize the scope of this change. It's only
intended to be as I described above. xorg.conf is not at present nor is
it intended to become entirely obsolete.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:13 p.m.
New subject: dontzap - a application to revert dontzap setting
On Tue, Mar 31, 2009 at 9:43 PM, Tomasz Torcz <tomek(a)pipebreaker.pl> wrote:
On Tue, Mar 31, 2009 at 11:00:21AM -0400, Bill Nottingham wrote:
> An app, a configuration framework with four differnet programs, all
> to twiddle one configuration line. Impressive.
And all of this for manipulating xorg.conf, which doesn't even exists
on modern distros.
You are obviously lucky enough to never had the need for a proprietary
GPU driver, otherwise you'd be accustomed to seeing xorg.conf
around...
Please note, pyhton-xkit is also a requirement for jockey (the tool to
detect hardware with proprietary drivers available)
--
Gianluca Sforna
http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna
4 p.m.
Tomasz Torcz wrote:
On Tue, Mar 31, 2009 at 11:00:21AM -0400, Bill Nottingham wrote:
> Rahul Sundaram (sundaram(a)fedoraproject.org) said:
>
>> https://launchpad.net/x-kit - DontZap is an application written in
>> Python which relies on X-Kit and allows users to set the "DontZap"
>> option in xorg.conf. Anyone interested in packaging this?
>>
>> You will need to package both x-kit and dontzap.
>>
> An app, a configuration framework with four differnet programs, all
> to twiddle one configuration line. Impressive.
>
And all of this for manipulating xorg.conf, which doesn't even exists
on modern distros.
yeah that's true, but all those emacs weenie's, and those dev's who
supposedly want to protect everyone from shooting themself in the foot,
want us who want to keep the X11 default regress to using an xorg.conf,
when in reality it is them who should be doing the regression and using
an xorg.conf to disable zapping!
5:57 p.m.
New subject: dontzap - a application to revert dontzap setting
On Tue, Mar 31, 2009 at 9:55 AM, Rahul Sundaram
<sundaram(a)fedoraproject.org>wrote:
Hi
https://launchpad.net/x-kit - DontZap is an application written in
Python which relies on X-Kit and allows users to set the "DontZap"
option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
Whoever want them, please be my guest:
http://orion.lcg.ufrj.br/RPMS/src/x-kit-0.4.2-1.fc10.src.rpm
http://orion.lcg.ufrj.br/RPMS/src/dontzap-0.1.2-1.fc10.src.rpm
I have some interest in x-kit, because it can be useful to alter
xorg.conf.
dontzap is just a bonus ...
--
Paulo Roma Cavalcanti
LCG - UFRJ
4:51 a.m.
New subject: dontzap - a application to revert dontzap setting
Paulo Cavalcanti wrote:
Whoever want them, please be my guest:
http://orion.lcg.ufrj.br/RPMS/src/x-kit-0.4.2-1.fc10.src.rpm
http://orion.lcg.ufrj.br/RPMS/src/dontzap-0.1.2-1.fc10.src.rpm
I have some interest in x-kit, because it can be useful to alter
xorg.conf.
dontzap is just a bonus ...
dontzap
https://bugzilla.redhat.com/show_bug.cgi?id=494518
x-kit
https://bugzilla.redhat.com/show_bug.cgi?id=494517
Rahul
5:33 a.m.
New subject: dontzap - a application to revert dontzap setting
On Tue, Apr 7, 2009 at 11:51 AM, Rahul Sundaram
<sundaram(a)fedoraproject.org> wrote:
dontzap
https://bugzilla.redhat.com/show_bug.cgi?id=494518
x-kit
https://bugzilla.redhat.com/show_bug.cgi?id=494517
I guess x-kit should be instead python-x-kit, or (IMHO even better)
pyhton-xkit like ubuntu does
http://packages.ubuntu.com/intrepid/python/python-xkit
--
Gianluca Sforna
http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna
5:45 a.m.
On Tuesday 31 March 2009 14:55:11 Rahul Sundaram wrote:
Hi
https://launchpad.net/x-kit - DontZap is an application written in
Python which relies on X-Kit and allows users to set the "DontZap"
option in xorg.conf. Anyone interested in packaging this?
You will need to package both x-kit and dontzap.
Rahul
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces
warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
Michal
5:54 a.m.
Michal Hlavinka wrote:
And what about
RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
They've chosen this way in opensuse - first time you press c+a+bs it produces
warning (bell) and second time it works as usual
And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it.
Meanwhile, x-kit is being used by a number of other programs and useful
to have in the repository. If you have x-kit, dontzap is just a small
script. No big deal.
Rahul
9:43 a.m.
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
Michal Hlavinka wrote:
> And what about
>
> RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
>
> They've chosen this way in opensuse - first time you press c+a+bs it produces
> warning (bell) and second time it works as usual
>
> And bonus: it uses less space than two new packages :o)
If and when the RFE's gets accepted, maybe. I wouldn't count on it.
Meanwhile, x-kit is being used by a number of other programs and useful
to have in the repository. If you have x-kit, dontzap is just a small
script. No big deal.
Please. Stop talking about xkit. We have a library for this already,
it's called pyxf86config. Writing the change to the X log is stupid if
you can also do it as a runtime XKB change, like mapping Caps Lock to
Compose like a sensible person.
The dontzap script is the wrong solution. Please stop suggesting it.
- ajax
9:53 a.m.
Adam Jackson wrote:
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
> Michal Hlavinka wrote:
>> And what about
>>
>> RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
>>
>> They've chosen this way in opensuse - first time you press c+a+bs it produces
>> warning (bell) and second time it works as usual
>>
>> And bonus: it uses less space than two new packages :o)
> If and when the RFE's gets accepted, maybe. I wouldn't count on it.
> Meanwhile, x-kit is being used by a number of other programs and useful
> to have in the repository. If you have x-kit, dontzap is just a small
> script. No big deal.
Please. Stop talking about xkit. We have a library for this already,
it's called pyxf86config.
I am aware of that.
Writing the change to the X log is stupid if
you can also do it as a runtime XKB change, like mapping Caps Lock
to
Compose like a sensible person.
Does that work currently?
The dontzap script is the wrong solution. Please stop suggesting it.
Do you have a current working solution that allows the users to easily
revert the setting?
Rahul
2:37 p.m.
Adam Jackson wrote:
On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
> Michal Hlavinka wrote:
>
>> And what about
>>
>> RFE: Zap after warning ( https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
>>
>> They've chosen this way in opensuse - first time you press c+a+bs it produces
>> warning (bell) and second time it works as usual
>>
>> And bonus: it uses less space than two new packages :o)
>>
> If and when the RFE's gets accepted, maybe. I wouldn't count on it.
> Meanwhile, x-kit is being used by a number of other programs and useful
> to have in the repository. If you have x-kit, dontzap is just a small
> script. No big deal.
>
Please. Stop talking about xkit. We have a library for this already,
it's called pyxf86config. Writing the change to the X log is stupid if
you can also do it as a runtime XKB change, like mapping Caps Lock to
Compose like a sensible person.
The dontzap script is the wrong solution. Please stop suggesting it.
- ajax
well since the xorg devs decided to disable x zapping please suggest the
right solution?
phil
2:46 p.m.
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
Adam Jackson wrote:
> Please. Stop talking about xkit. We have a library for this already,
> it's called pyxf86config. Writing the change to the X log is stupid if
> you can also do it as a runtime XKB change, like mapping Caps Lock to
> Compose like a sensible person.
well since the xorg devs decided to disable x zapping please suggest the
right solution?
I said it. Right there. The bit about being a runtime XKB feature
already.
- ajax (an xorg dev)
3:02 p.m.
Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
> Adam Jackson wrote:
>
>> Please. Stop talking about xkit. We have a library for this already,
>> it's called pyxf86config. Writing the change to the X log is stupid if
>> you can also do it as a runtime XKB change, like mapping Caps Lock to
>> Compose like a sensible person.
>>
> well since the xorg devs decided to disable x zapping please suggest the
> right solution?
>
I said it. Right there. The bit about being a runtime XKB feature
already.
- ajax (an xorg dev)
and you think an average user will know how to do this compared to
installing rahuls dontzap package, and maybe just maybe when the next
big change comes around in xorg you could let the community know
beforehand instead of thinking your godlike
phil - glad not to be an xorg dev ;)
5:06 p.m.
On Tue, 2009-04-07 at 21:02 +0100, psmith wrote:
Adam Jackson wrote:
> On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
>> Adam Jackson wrote:
>>> Please. Stop talking about xkit. We have a library for this already,
>>> it's called pyxf86config. Writing the change to the X log is stupid if
>>> you can also do it as a runtime XKB change, like mapping Caps Lock to
>>> Compose like a sensible person.
>>>
>> well since the xorg devs decided to disable x zapping please suggest the
>> right solution?
>>
>
> I said it. Right there. The bit about being a runtime XKB feature
> already.
>
and you think an average user will know how to do this compared to
installing rahuls dontzap package, and maybe just maybe when the next
big change comes around in xorg you could let the community know
beforehand instead of thinking your godlike
My godlike what?
All the other runtime XKB features are pretty well discoverable.
gnome-keyboard-properties, layouts, layout options.
- ajax
8:40 a.m.
Adam Jackson wrote:
On Tue, 2009-04-07 at 21:02 +0100, psmith wrote:
> Adam Jackson wrote:
>
>> On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
>>
>>> Adam Jackson wrote:
>>>
>>>> Please. Stop talking about xkit. We have a library for this already,
>>>> it's called pyxf86config. Writing the change to the X log is stupid
if
>>>> you can also do it as a runtime XKB change, like mapping Caps Lock to
>>>> Compose like a sensible person.
>>>>
>>>>
>>> well since the xorg devs decided to disable x zapping please suggest the
>>> right solution?
>>>
>>>
>> I said it. Right there. The bit about being a runtime XKB feature
>> already.
>>
>>
> and you think an average user will know how to do this compared to
> installing rahuls dontzap package, and maybe just maybe when the next
> big change comes around in xorg you could let the community know
> beforehand instead of thinking your godlike
>
My godlike what?
All the other runtime XKB features are pretty well discoverable.
gnome-keyboard-properties, layouts, layout options.
- ajax
godlike as in taking votes on changes that will effect every xorg user
in hidden polls, after all the discussions held previously and since
were against the change, (apart for the few who hit keys aimlessly to
see what happens or those who don't type to well) and not asking the
community you are supposedly part of what they think, or even letting
them know it was on the cards, anyway i've had enough of this i'll
either patch the x source myself to put it back or live with regressing
to using an xorg.conf, just to please the aforementioned few!
phil
12:29 a.m.
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
> Adam Jackson wrote:
> > Please. Stop talking about xkit. We have a library for this already,
> > it's called pyxf86config. Writing the change to the X log is stupid if
> > you can also do it as a runtime XKB change, like mapping Caps Lock to
> > Compose like a sensible person.
>
> well since the xorg devs decided to disable x zapping please suggest the
> right solution?
I said it. Right there. The bit about being a runtime XKB feature
already.
Even though the time I most likely want ctl-alt-bs is BEFORE any login,
and quite possibly before GDM has even run, because the video driver is
b0rked?
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it
as part of the user login process. Are we expecting people to be using
Emacs at the GDM login screen?
12:38 a.m.
New subject: dontzap - a application to revert dontzap setting
On Wed, Apr 8, 2009 at 1:29 AM, Callum Lerwick wrote:
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
> On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
> > Adam Jackson wrote:
> > > Please. Stop talking about xkit. We have a library for this already,
> > > it's called pyxf86config. Writing the change to the X log is stupid
if
> > > you can also do it as a runtime XKB change, like mapping Caps Lock to
> > > Compose like a sensible person.
> >
> > well since the xorg devs decided to disable x zapping please suggest the
> > right solution?
>
> I said it. Right there. The bit about being a runtime XKB feature
> already.
Even though the time I most likely want ctl-alt-bs is BEFORE any login,
and quite possibly before GDM has even run, because the video driver is
b0rked?
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it
as part of the user login process. Are we expecting people to be using
Emacs at the GDM login screen?
You sound desperate. I believe that it is best to save your energy for
fighting with xorg people. While I find disabling c-a-b utterly
stupid, I do not think this is the place that I should try to convince
people.
Orcan, the "proud emacs user"
12:40 a.m.
Callum Lerwick wrote:
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE
it
as part of the user login process. Are we expecting people to be using
Emacs at the GDM login screen?
Please stop rehashing the same old discussions in this thread as well.
No need for the emacs conspiracy theory all over again.
http://www.fooishbar.org/blog/tech/x/ctrl-alt-backspace-2009-04-04-00-37....
Rahul
11:25 a.m.
On Wed, 2009-04-08 at 11:10 +0530, Rahul Sundaram wrote:
Callum Lerwick wrote:
> Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it
> as part of the user login process. Are we expecting people to be using
> Emacs at the GDM login screen?
Please stop rehashing the same old discussions in this thread as well.
No need for the emacs conspiracy theory all over again.
Its not the same old discussion, its an entirely new suggestion. I
mention emacs out of sarcasm, and perhaps a metaphor. Lighten up. It's
still a serious suggestion. Notice how *I* have been trying to offer
alternatives amenable to both sides, rather than just whining about
reverting the change.
There have been THREE realistic suggestions for how to retain the
functionality without nuking the functionality entirely, while still
recognizing that ctl-alt-bs IS possible to accidentally hit.
1) Make the key combo more obscure. ctl-alt-lshift-rshift-bs
2) The SUSE patch, require hitting it twice
3) Enable by default, disable by default once in a user session.
All three are independent, and all three can be implemented if you think
the X server hasn't been nerfed enough yet.
3:51 a.m.
On Wednesday 08 April 2009 07:29:59 Callum Lerwick wrote:
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
> On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
> > Adam Jackson wrote:
> > > Please. Stop talking about xkit. We have a library for this
> > > already, it's called pyxf86config. Writing the change to the X log
> > > is stupid if you can also do it as a runtime XKB change, like mapping
> > > Caps Lock to Compose like a sensible person.
> >
> > well since the xorg devs decided to disable x zapping please suggest
> > the right solution?
>
> I said it. Right there. The bit about being a runtime XKB feature
> already.
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it
as part of the user login process. Are we expecting people to be using
Emacs at the GDM login screen?
<JOKE>And what about setting Conflicts: emacs in dontzap package ? :) </JOKE>
Anyway, I think this discussion is useless. Because there are not millions of
grumbling users, there will be no will to change it...
4:28 a.m.
* Michal Hlavinka <mhlavink(a)redhat.com> [20090408 10:51]:
On Wednesday 08 April 2009 07:29:59 Callum Lerwick wrote:
> Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it
> as part of the user login process. Are we expecting people to be using
> Emacs at the GDM login screen?
The emacs conspiracy is getting seriously tired now...
<JOKE>And what about setting Conflicts: emacs in dontzap
package ? :) </JOKE>
*grin* Not a bad suggestion.
Anyway, I think this discussion is useless. Because there are not
millions of
grumbling users, there will be no will to change it...
There are some very vocal users that don't like the change. I had a
look at the man page for xorg.conf and one argument that's been
floated here is that applications grab focus and then misbehave.
Has anyone looked at and tested the AllowDeactivateGrabs and
AllowClosedownGrabs options in their xorg.conf instead of blindly
relying on C-A-Bs to shoot the server in the head? If they still have
keyboard interrupt, these options may actually be a better solution
than killing the entire X server.
Just a thought.
--
/Anders
4:32 a.m.
New subject: dontzap - a application to revert dontzap setting
Alright, I can't resist it anymore, I just have to throw in my $0.02
(or €0.015). :)
This discussion has gone everywhere by now and it might be just me,
but what exactly *is* the big deal here? Upstream decided to make a
change to the shortcut behavior. It's been well spoken of by now.
People have blogged about it. It's in the release notes (isn't that
what it's for?). The excuse "people don't read release notes" does not
apply at all here (IMHO). When they run into the "problem" they could
have known it (what's the term again? RTFM?).
Besides the fact that it's disabled by default doesn't mean it can be
reverted. There have been various solutions by now, they just need to
be well documented to work. Sure, a checkbox in a configuration tool
would be nice for the less experienced user, but is making a change to
(perhaps a non existing) xorg.conf file that hard when it's been well
documented? I guess it's just as hard as installing a 3th party piece
of software which is currently not in the Fedora repo's. It'd require
some knowledge of the software you're working with.
Please keep in mind that I'm just thinking out loud here. There are no
bad intentions in my post and I'm not trying to defend the change
(although I can live with it perfectly fine). I'm just trying to
figure out what it's all about.
PS. Also, I might even have missed out on some important statements.
Feel free to let me know if I'm (completely) wrong here.
4:33 p.m.
Anders Rayner-Karlsson wrote:
Has anyone looked at and tested the AllowDeactivateGrabs and
AllowClosedownGrabs options in their xorg.conf instead of blindly
relying on C-A-Bs to shoot the server in the head? If they still have
keyboard interrupt, these options may actually be a better solution
than killing the entire X server.
I looked at them while struggling with
https://bugzilla.redhat.com/show_bug.cgi?id=473825... they didn't work
(probably because the actual problem in said bug was not, in fact, a bad
grab, but something a little stranger). In the process of investigating
them, I learned they had (reportedly) been removed in current X.org.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
このテキストを翻訳する時間の無駄だばかばかしい
5:42 p.m.
* Matthew Woehlke <mw_triad(a)users.sourceforge.net> [20090408 23:34]:
Anders Rayner-Karlsson wrote:
> Has anyone looked at and tested the AllowDeactivateGrabs and
> AllowClosedownGrabs options in their xorg.conf instead of blindly
> relying on C-A-Bs to shoot the server in the head? If they still have
> keyboard interrupt, these options may actually be a better solution
> than killing the entire X server.
I looked at them while struggling with
https://bugzilla.redhat.com/show_bug.cgi?id=473825... they didn't work
(probably because the actual problem in said bug was not, in fact, a bad
grab, but something a little stranger). In the process of investigating
them, I learned they had (reportedly) been removed in current X.org.
So it has.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f...
Thanks for pointing that out.
--
/Anders
5:42 a.m.
On Wednesday 08 April 2009 23:42:25 Anders Rayner-Karlsson wrote:
* Matthew Woehlke <mw_triad(a)users.sourceforge.net> [20090408
23:34]:
> Anders Rayner-Karlsson wrote:
>> Has anyone looked at and tested the AllowDeactivateGrabs and
>> AllowClosedownGrabs options in their xorg.conf instead of blindly
>> relying on C-A-Bs to shoot the server in the head? If they still have
>> keyboard interrupt, these options may actually be a better solution
>> than killing the entire X server.
>
> I looked at them while struggling with
> https://bugzilla.redhat.com/show_bug.cgi?id=473825... they didn't work
> (probably because the actual problem in said bug was not, in fact, a bad
> grab, but something a little stranger). In the process of investigating
> them, I learned they had (reportedly) been removed in current X.org.
So it has.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38
b47104a26c0524385
Thanks for pointing that out.
Is there actually any kind of replacement for this? Because I have had to use
that feature many, many times (usually due to a browser "hanging", and yes, I
know it would be nice to fix all the bugs, but ...).
8:29 a.m.
On Wed, 2009-04-08 at 00:29 -0500, Callum Lerwick wrote:
On Tue, 2009-04-07 at 15:46 -0400, Adam Jackson wrote:
> On Tue, 2009-04-07 at 20:37 +0100, psmith wrote:
> > Adam Jackson wrote:
> > > Please. Stop talking about xkit. We have a library for this already,
> > > it's called pyxf86config. Writing the change to the X log is stupid
if
> > > you can also do it as a runtime XKB change, like mapping Caps Lock to
> > > Compose like a sensible person.
> >
> > well since the xorg devs decided to disable x zapping please suggest the
> > right solution?
>
> I said it. Right there. The bit about being a runtime XKB feature
> already.
Even though the time I most likely want ctl-alt-bs is BEFORE any login,
and quite possibly before GDM has even run, because the video driver is
b0rked?
Hey I have a genius idea. ENABLE ctl-alt-bs by default, and DISABLE it
as part of the user login process. Are we expecting people to be using
Emacs at the GDM login screen?
This is an entirely reasonable idea, but again, gdm is completely
capable of doing this itself without modifying xorg.conf.
- ajax
2:58 p.m.
On 4/7/2009 3:37 PM, psmith wrote:
Adam Jackson wrote:
> On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
>> Michal Hlavinka wrote:
>>> And what about
>>> RFE: Zap after warning (
>>> https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
>>> They've chosen this way in opensuse - first time you
press c+a+bs it
>>> produces warning (bell) and second time it works as usual
>>> And bonus: it uses less space than two new packages :o)
>> If and when the RFE's gets accepted, maybe. I
wouldn't count on it.
>> Meanwhile, x-kit is being used by a number of other programs and useful
>> to have in the repository. If you have x-kit, dontzap is just a small
>> script. No big deal.
> Please. Stop talking about xkit. We have a library for this
already,
> it's called pyxf86config. Writing the change to the X log is stupid if
> you can also do it as a runtime XKB change, like mapping Caps Lock to
> Compose like a sensible person.
> The dontzap script is the wrong solution. Please stop suggesting
it.
> - ajax
well since the xorg devs decided to disable x zapping please suggest
the
right solution?
How about trying this? 'Put it back in yourself'. ;-)
It looks like this.
Section "ServerFlags"
Option "DontZap" "false"
EndSection
--
David
3:18 p.m.
David wrote:
On 4/7/2009 3:37 PM, psmith wrote:
> Adam Jackson wrote:
>
>> On Tue, 2009-04-07 at 16:24 +0530, Rahul Sundaram wrote:
>>
>>> Michal Hlavinka wrote:
>>>
>>>> And what about
>>>>
>>>> RFE: Zap after warning (
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=494528 )
>>>>
>>>> They've chosen this way in opensuse - first time you press c+a+bs it
>>>> produces warning (bell) and second time it works as usual
>>>>
>>>> And bonus: it uses less space than two new packages :o)
>>>>
>>> If and when the RFE's gets accepted, maybe. I wouldn't count on it.
>>> Meanwhile, x-kit is being used by a number of other programs and useful
>>> to have in the repository. If you have x-kit, dontzap is just a small
>>> script. No big deal.
>>>
>> Please. Stop talking about xkit. We have a library for this already,
>> it's called pyxf86config. Writing the change to the X log is stupid if
>> you can also do it as a runtime XKB change, like mapping Caps Lock to
>> Compose like a sensible person.
>>
>> The dontzap script is the wrong solution. Please stop suggesting it.
>>
>> - ajax
>>
> well since the xorg devs decided to disable x zapping please suggest the
> right solution?
>
How about trying this? 'Put it back in yourself'. ;-)
It looks like this.
Section "ServerFlags"
Option "DontZap" "false"
EndSection
and since were supposed to be moving away from using an xorg.conf all of
us who want to be able to restart x (and believe me as good as those
xorg devs think their code is it still happens quite regularly) without
having to go to a virtual terminal etc have to regress to using one to
keep people who want to make linux like windows or those emacs users who
don't type to well happy.
phil
1:30 a.m.
On 04/07/2009 01:18 PM, psmith wrote:
David wrote:
> Section "ServerFlags"
> Option "DontZap" "false"
> EndSection
>
>
and since were supposed to be moving away from using an xorg.conf all of
us who want to be able to restart x (and believe me as good as those
xorg devs think their code is it still happens quite regularly) without
having to go to a virtual terminal etc have to regress to using one to
keep people who want to make linux like windows or those emacs users who
don't type to well happy.
So, an alternate suggestion is just don't upgrade to F11. I do not
recommend that personally, but the new behavior is only in F11+ so if
you don't upgrade, Ctrl+Alt+Backspace will continue to work.
Or, if you decide to upgrade, just use a kickstart file when you do.
You've established you're going to be using anaconda to upgrade since in
order to do a yum upgrade, you'd have to edit a few .repo files, and
you've made it clear that you won't be editing files.
I already posted earlier in this thread[1] what the kickstart file has
to look like. It's now also on fpaste[2]. Simply point anaconda to it
by appending ks=[2] to the boot line, and then you will have an
xorg.conf containing the needed lines to maintain Ctrl+Alt+Backspace.
No vts required.
[1]
https://www.redhat.com/archives/fedora-devel-list/2009-March/msg02161.html
[2] http://fpaste.org/paste/8338/plain
5489
days inactive
5498
days old
35 comments
19 participants
participants (19)
-
Adam Jackson -
Adam Miller -
Adam Williamson -
Anders Rayner-Karlsson -
Bill Crawford -
Bill Nottingham -
Callum Lerwick -
Christopher Aillon -
David Boles -
Eelko Berkenpies -
Gianluca Sforna -
Jarod Wilson -
jon doe -
Matthew Woehlke -
Michal Hlavinka -
Orcan Ogetbil -
Paulo Cavalcanti -
Rahul Sundaram -
Tomasz Torcz