[gentoo-user] scrapping hal

[gentoo-user] scrapping hal

[Harry Putnam]

I've been off the list a good while and wondered if there is some kind
of guide to scrap hal.

I understand it is being done away with upstream and will probably
require some changes on users part.

I'm also guessing there is some kind of replacement that I need to
learn about if it effects my longtime reliance on xorg.conf to keep
using my huge desktops I like to use.  For yrs I've
used.

    Subsection "Display"
        Depth       24
        Modes       "1280x1024" #"1024x768" "800x600" "640x480"
        Virtual     2048 1536 
        ViewPort    0 0
    EndSubsection
EndSection

in /etc/X11/xorg.conf
To get a 2048x1536 desktop to flop around on.

I've never seen or heard of a way to get that without using xorg.conf.

Other things, I noticed was the onetime I did try to dump hal I ended
up with no mouse or keyboard and fiddled with that a couple days,
finally going back to hal.

That has been probably a yr or more ago now.

Back to the point:  Can anyone provide some URLS that will help me
form a battle plan or even better a brief outline of (generally) how
to proceed with more or less painlessly dumping hal?

Re: [gentoo-user] scrapping hal

[Alan McKinnon]

Apparently, though unproven, at 23:06 on Wednesday 27 October 2010, Harry 
Putnam did opine thusly:

> I've been off the list a good while and wondered if there is some kind
> of guide to scrap hal.
> 
> I understand it is being done away with upstream and will probably
> require some changes on users part.
> 
> I'm also guessing there is some kind of replacement that I need to
> learn about if it effects my longtime reliance on xorg.conf to keep
> using my huge desktops I like to use.  For yrs I've
> used.
> 
>     Subsection "Display"
>         Depth       24
>         Modes       "1280x1024" #"1024x768" "800x600" "640x480"
>         Virtual     2048 1536
>         ViewPort    0 0
>     EndSubsection
> EndSection
> 
> in /etc/X11/xorg.conf
> To get a 2048x1536 desktop to flop around on.
> 
> I've never seen or heard of a way to get that without using xorg.conf.
> 
> Other things, I noticed was the onetime I did try to dump hal I ended
> up with no mouse or keyboard and fiddled with that a couple days,
> finally going back to hal.
> 
> That has been probably a yr or more ago now.
> 
> Back to the point:  Can anyone provide some URLS that will help me
> form a battle plan or even better a brief outline of (generally) how
> to proceed with more or less painlessly dumping hal?

It should all just work automagically with no real effort from you.

However, you cannot just unmerge hal and expect stuff to work, you might still 
need it, as in:

$ emerge -pv --depclean hal

Calculating dependencies... done!
  sys-apps/hal-0.5.14-r3 pulled in by:
    app-cdr/k3b-2.0.1
    app-emulation/virtualbox-ose-3.2.10
    app-misc/hal-info-20091130
    dev-libs/e_dbus-9999
    kde-base/solid-4.5.2
    media-gfx/gimp-2.6.10
    media-libs/libgphoto2-2.4.9

Recent xorg-server (i.e. 1.9.1 do not have hal in USE anymore. For earlier 
versions, you may still need to set USE=-hal udev for xorg-server in 
package.use. Then rebuild xorg-server. If you are *updating* xorg-server while 
doing this, then you might need to rebuild mesa and all the drivers as usual 
for an xorg update.

As for xorg.conf. It's not quite true that you don't need an xorg.conf - this 
is still needed to define Screens and Devices if you have more than just one 
video adapter at native resolution. The part you don't need without hal is the 
Input section.

Once you have rebuilt xorg-server and made sure you run a recent udev plus 
evdev in the kernel, comment out ALL Input sections in xorg.conf and all 
references to them. Restart X.

It should all JustWork(tm). In the rare event it doesn't, post back with logs 
etc and we'll take it from there.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] scrapping hal

[Paul Hartman]

On Wed, Oct 27, 2010 at 4:06 PM, Harry Putnam <reader@newsguy.com> wrote:
> I'm also guessing there is some kind of replacement that I need to
> learn about if it effects my longtime reliance on xorg.conf to keep
> using my huge desktops I like to use.  For yrs I've
> used.
>
>    Subsection "Display"
>        Depth       24
>        Modes       "1280x1024" #"1024x768" "800x600" "640x480"
>        Virtual     2048 1536
>        ViewPort    0 0
>    EndSubsection
> EndSection
>
> in /etc/X11/xorg.conf
> To get a 2048x1536 desktop to flop around on.
>
> I've never seen or heard of a way to get that without using xorg.conf.

I think you would use xrandr to set it, or your desktop environment's
GUI settings panel (or equivalent).

Re: [gentoo-user] scrapping hal

[Paul Hartman]

On Wed, Oct 27, 2010 at 4:31 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Wed, Oct 27, 2010 at 4:06 PM, Harry Putnam <reader@newsguy.com> wrote:
>> I'm also guessing there is some kind of replacement that I need to
>> learn about if it effects my longtime reliance on xorg.conf to keep
>> using my huge desktops I like to use.  For yrs I've
>> used.
>>
>>    Subsection "Display"
>>        Depth       24
>>        Modes       "1280x1024" #"1024x768" "800x600" "640x480"
>>        Virtual     2048 1536
>>        ViewPort    0 0
>>    EndSubsection
>> EndSection
>>
>> in /etc/X11/xorg.conf
>> To get a 2048x1536 desktop to flop around on.
>>
>> I've never seen or heard of a way to get that without using xorg.conf.
>
> I think you would use xrandr to set it, or your desktop environment's
> GUI settings panel (or equivalent).

Also, I think if you still need to use an xorg.conf file if you want
to use the proprietary NVIDIA or ATI drivers. If you're using the
standard xorg drivers then it should all probe and configure
automagically. In theory. :)

Re: [gentoo-user] scrapping hal

[Philip Webb]

101027 Harry Putnam wrote:
> I wondered if there is some kind of guide to scrap hal.

From my notes, having done it on  2  desktops machines +  1  netbook :

  To remove Hal : drop '-hal' flag, add 'udev' flag ;
                  update to  Xorg-server >= 1.8.0  -drivers >= 1.8
                             Xinit >= 1.2.1  + drivers ;
                  re-merge Exo Thunar ;
                  delete refs to 'mouse' 'keyboard' in  xorg.conf ;
                  remove 'hald' fr  /etc/runlevels/default/ . 

IIRC Hal is needed to the KDE desktop, but not for most KDE apps;
I use Fluxbox + quite a few KDE apps; Exo Thunar belong to Xfce.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

[gentoo-user] Re: scrapping hal

[Harry Putnam]

Philip Webb <purslow@ca.inter.net> writes:

> 101027 Harry Putnam wrote:
>> I wondered if there is some kind of guide to scrap hal.
>
> From my notes, having done it on  2  desktops machines +  1  netbook :

Nice .. many thanks but one question....
>
>   To remove Hal : drop '-hal' flag, add 'udev' flag ;

    So no kind of hal flag in make.conf, or is `-hal' a typo that
    should be `drop 'hal' flag?

[gentoo-user] Re: scrapping hal

[Harry Putnam]

Philip Webb <purslow@ca.inter.net> writes:

> 101027 Harry Putnam wrote:
>> I wondered if there is some kind of guide to scrap hal.
>
> From my notes, having done it on  2  desktops machines +  1  netbook :

Nice .. many thanks but one question....
>
>   To remove Hal : drop '-hal' flag, add 'udev' flag ;

So no kind of hal flag in make.conf, or is `-hal' a typo that
should be `drop 'hal' flag?

Re: [gentoo-user] scrapping hal

[Dale]

Philip Webb wrote:
> 101027 Harry Putnam wrote:
>    
>> I wondered if there is some kind of guide to scrap hal.
>>      
> > From my notes, having done it on  2  desktops machines +  1  netbook :
>
>    To remove Hal : drop '-hal' flag, add 'udev' flag ;
>                    update to  Xorg-server>= 1.8.0  -drivers>= 1.8
>                               Xinit>= 1.2.1  + drivers ;
>                    re-merge Exo Thunar ;
>                    delete refs to 'mouse' 'keyboard' in  xorg.conf ;
>                    remove 'hald' fr  /etc/runlevels/default/ .
>
> IIRC Hal is needed to the KDE desktop, but not for most KDE apps;
> I use Fluxbox + quite a few KDE apps; Exo Thunar belong to Xfce.
>
>    

I think KDE is moving away from hal to tho.  I read somewhere the switch 
is coming.  I think it is switching to policykit at some point.  I 
notice it is already in the USE flags for kdelibs here, disabled here at 
the moment tho.  That would be if it doesn't change again.

Dale

:-)  :-)

[gentoo-user] Re: scrapping hal

[Harry Putnam]

Paul Hartman <paul.hartman+gentoo@gmail.com> writes:

> On Wed, Oct 27, 2010 at 4:06 PM, Harry Putnam <reader@newsguy.com> wrote:
>> I'm also guessing there is some kind of replacement that I need to
>> learn about if it effects my longtime reliance on xorg.conf to keep
>> using my huge desktops I like to use.  For yrs I've
>> used.
>>
>>    Subsection "Display"
>>        Depth       24
>>        Modes       "1280x1024" #"1024x768" "800x600" "640x480"
>>        Virtual     2048 1536
>>        ViewPort    0 0
>>    EndSubsection
>> EndSection
>>
>> in /etc/X11/xorg.conf
>> To get a 2048x1536 desktop to flop around on.
>>
>> I've never seen or heard of a way to get that without using xorg.conf.
>
> I think you would use xrandr to set it, or your desktop environment's
> GUI settings panel (or equivalent).

I may be using xrandr wrong but it doesn't do the trick used like
this:

I'm running an `emerge world' so didn't want to close down X so I used
Ctrl-alt F1 to leave X and then Ctrl-alt F2 to login on a different
virtual terminal.

Then commented out the `Virtual' line in xorg.conf:

    EndSubsection
    Subsection "Display"
        Depth       24
        Modes       "1280x1024" #"1024x768" "800x600" "640x480"
#        Virtual     2048 1536 
        ViewPort    0 0
    EndSubsection
EndSection


Then startx on a different display.

  startx -- :1

Once X is up:

  xrandr <no args>
  shows 1280x1024 as being the highest resolution.


  xrandr -s 2048x1536 shows:

  Size  2048x1536 not found in available modes

The xfce display setting tool also shows 1280 as the highest possible
setting.

I've asked before where else this might be set... in more than 1
forum.  I think you may find its not all that easy to set a Resolution
way higher than your card supports.

Re: [gentoo-user] Re: scrapping hal

[Paul Colquhoun]

On Thu, 28 Oct 2010 14:54:51 Harry Putnam wrote:
> Paul Hartman <paul.hartman+gentoo@gmail.com> writes:
> > On Wed, Oct 27, 2010 at 4:06 PM, Harry Putnam <reader@newsguy.com> wrote:
> >> I'm also guessing there is some kind of replacement that I need to
> >> learn about if it effects my longtime reliance on xorg.conf to keep
> >> using my huge desktops I like to use.  For yrs I've
> >> used.
> >> 
> >>    Subsection "Display"
> >>        Depth       24
> >>        Modes       "1280x1024" #"1024x768" "800x600" "640x480"
> >>        Virtual     2048 1536
> >>        ViewPort    0 0
> >>    EndSubsection
> >> EndSection
> >> 
> >> in /etc/X11/xorg.conf
> >> To get a 2048x1536 desktop to flop around on.
> >> 
> >> I've never seen or heard of a way to get that without using xorg.conf.
> > 
> > I think you would use xrandr to set it, or your desktop environment's
> > GUI settings panel (or equivalent).
> 
> I may be using xrandr wrong but it doesn't do the trick used like
> this:
> 
> I'm running an `emerge world' so didn't want to close down X so I used
> Ctrl-alt F1 to leave X and then Ctrl-alt F2 to login on a different
> virtual terminal.
> 
> Then commented out the `Virtual' line in xorg.conf:
> 
>     EndSubsection
>     Subsection "Display"
>         Depth       24
>         Modes       "1280x1024" #"1024x768" "800x600" "640x480"
> #        Virtual     2048 1536
>         ViewPort    0 0
>     EndSubsection
> EndSection
> 
> 
> Then startx on a different display.
> 
>   startx -- :1
> 
> Once X is up:
> 
>   xrandr <no args>
>   shows 1280x1024 as being the highest resolution.
> 
> 
>   xrandr -s 2048x1536 shows:
> 
>   Size  2048x1536 not found in available modes
> 
> The xfce display setting tool also shows 1280 as the highest possible
> setting.
> 
> I've asked before where else this might be set... in more than 1
> forum.  I think you may find its not all that easy to set a Resolution
> way higher than your card supports.


Did you look at the man page for xrandr?

I think you need the "--fb" & "--panning" options. There is even an example 
towards the end of the man page.


-- 
Reverend Paul Colquhoun, ULC.    http://andor.dropbear.id.au/~paulcol
 Before you criticize someone, you should walk a mile in their shoes.
Then, when you do, you'll be a mile away, and you'll have their shoes.

Re: [gentoo-user] Re: scrapping hal

[Alan McKinnon]

Apparently, though unproven, at 05:22 on Thursday 28 October 2010, Harry 
Putnam did opine thusly:

> Philip Webb <purslow@ca.inter.net> writes:
> > 101027 Harry Putnam wrote:
> >> I wondered if there is some kind of guide to scrap hal.
> > 
> > From my notes, having done it on  2  desktops machines +  1  netbook :
> Nice .. many thanks but one question....
> 
> >   To remove Hal : drop '-hal' flag, add 'udev' flag ;
> 
> So no kind of hal flag in make.conf, or is `-hal' a typo that
> should be `drop 'hal' flag?


I wouldn't advise putting -hal in make.conf - that's globally and too many 
other things on the desktop still need it. Either

a) disable it in /etc/make.conf and enable it in packages.use for stuff that 
needs it
b) enable it in make.conf and disable it in packages.use for xorg-server

I prefer b) as it's too easy to miss things using a).


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] scrapping hal

[Peter Humphrey]

On Thursday 28 October 2010 04:50:18 Dale wrote:

> I think KDE is moving away from hal to tho.  I read somewhere the
> switch is coming.  I think it is switching to policykit at some
> point.  I notice it is already in the USE flags for kdelibs here,
> disabled here at the moment tho.  That would be if it doesn't change
> again.

On this ~amd64 box:

$ emerge -pv xorg-server
[...]
[ebuild   R   ] x11-base/xorg-server-1.9.1  USE="ipv6 nptl udev xorg -
dmx -doc -kdrive -minimal 

No mention of hal there.

-- 
Rgds
Peter.          Linux Counter 5290, 1994-04-23.

Re: [gentoo-user] scrapping hal

[Dale]

Peter Humphrey wrote:
> On Thursday 28 October 2010 04:50:18 Dale wrote:
>
>    
>> I think KDE is moving away from hal to tho.  I read somewhere the
>> switch is coming.  I think it is switching to policykit at some
>> point.  I notice it is already in the USE flags for kdelibs here,
>> disabled here at the moment tho.  That would be if it doesn't change
>> again.
>>      
> On this ~amd64 box:
>
> $ emerge -pv xorg-server
> [...]
> [ebuild   R   ] x11-base/xorg-server-1.9.1  USE="ipv6 nptl udev xorg -
> dmx -doc -kdrive -minimal
>
> No mention of hal there.
>
>    

They are probably already moved away from hal.  Everybody knows it is 
going and that is a bleeding edge version of xorg too.  I'm still on 1.7.*.

Which brings me to my next question.  How is xorg 1.9 working for ya?  
Any gotchas?  May try it here.

Dale

:-)  :-)

Re: [gentoo-user] scrapping hal

[Peter Humphrey]

On Thursday 28 October 2010 11:46:30 Dale wrote:

> Which brings me to my next question.  How is xorg 1.9 working for ya?
> Any gotchas?  May try it here.

No problems so far. I had to unmask a more recent version of xorg 
because version 1.7.7 was incompatible with kernel 2.6.36. Well, I could 
have gone back to an earlier kernel, but what the hell?

-- 
Rgds
Peter.          Linux Counter 5290, 1994-04-23.

Re: [gentoo-user] scrapping hal

[Alan McKinnon]

Apparently, though unproven, at 12:46 on Thursday 28 October 2010, Dale did 
opine thusly:

> Peter Humphrey wrote:
> > On Thursday 28 October 2010 04:50:18 Dale wrote:
> >> I think KDE is moving away from hal to tho.  I read somewhere the
> >> switch is coming.  I think it is switching to policykit at some
> >> point.  I notice it is already in the USE flags for kdelibs here,
> >> disabled here at the moment tho.  That would be if it doesn't change
> >> again.
> > 
> > On this ~amd64 box:
> > 
> > $ emerge -pv xorg-server
> > [...]
> > [ebuild   R   ] x11-base/xorg-server-1.9.1  USE="ipv6 nptl udev xorg -
> > dmx -doc -kdrive -minimal
> > 
> > No mention of hal there.
> 
> They are probably already moved away from hal.  Everybody knows it is
> going and that is a bleeding edge version of xorg too.  I'm still on 1.7.*.
> 
> Which brings me to my next question.  How is xorg 1.9 working for ya?
> Any gotchas?  May try it here.

xorg-server 1.8 and 1.9 use mesa-7.8.2, and there's reports around that that 
version of mesa causes desktop slowdowns. mesa-7.7.1 as used by xorg-
server-1.7 is reported to be fine

Me, I'm undecided. I have a slow sluggish desktop, but it might be the nvidia 
drivers, mesa, X-server, kernel config, wrong elevator or even just the shitty 
IO scheduler design on desktops that the kernel devs are recently waking up to 
admitting to. Lots of stuff to change one at a time and see what results...


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] scrapping hal

[Dale]

Alan McKinnon wrote:
> Apparently, though unproven, at 12:46 on Thursday 28 October 2010, Dale did
> opine thusly:
>
>    
>> Peter Humphrey wrote:
>>      
>>> On Thursday 28 October 2010 04:50:18 Dale wrote:
>>>        
>>>> I think KDE is moving away from hal to tho.  I read somewhere the
>>>> switch is coming.  I think it is switching to policykit at some
>>>> point.  I notice it is already in the USE flags for kdelibs here,
>>>> disabled here at the moment tho.  That would be if it doesn't change
>>>> again.
>>>>          
>>> On this ~amd64 box:
>>>
>>> $ emerge -pv xorg-server
>>> [...]
>>> [ebuild   R   ] x11-base/xorg-server-1.9.1  USE="ipv6 nptl udev xorg -
>>> dmx -doc -kdrive -minimal
>>>
>>> No mention of hal there.
>>>        
>> They are probably already moved away from hal.  Everybody knows it is
>> going and that is a bleeding edge version of xorg too.  I'm still on 1.7.*.
>>
>> Which brings me to my next question.  How is xorg 1.9 working for ya?
>> Any gotchas?  May try it here.
>>      
> xorg-server 1.8 and 1.9 use mesa-7.8.2, and there's reports around that that
> version of mesa causes desktop slowdowns. mesa-7.7.1 as used by xorg-
> server-1.7 is reported to be fine
>
> Me, I'm undecided. I have a slow sluggish desktop, but it might be the nvidia
> drivers, mesa, X-server, kernel config, wrong elevator or even just the shitty
> IO scheduler design on desktops that the kernel devs are recently waking up to
> admitting to. Lots of stuff to change one at a time and see what results...
>
>    

Since you are undecided, I'm decided.  I'm sticking with what I have 
now.  I just got mine to speed up again and I don't want to be trying to 
narrow down problems again.

What's the old saying, if it's working, don't fix it.  lol

Dale

:-)  :-)

Re: [gentoo-user] scrapping hal

[Alan McKinnon]

Apparently, though unproven, at 16:36 on Thursday 28 October 2010, Dale did 
opine thusly:

> What's the old saying, if it's working, don't fix it.

"What's the old saying, if it's working, don't fix it, until it's ancient, not 
supported and your box won't update world anymore so you are up the creek 
without a paddle and shit outta luck"

There ya go, fixed that for ya Dale :-)


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: scrapping hal

[Fatih Tümen]

On Thu, Oct 28, 2010 at 11:26, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Apparently, though unproven, at 05:22 on Thursday 28 October 2010, Harry
> Putnam did opine thusly:
>
>> Philip Webb <purslow@ca.inter.net> writes:
>> > 101027 Harry Putnam wrote:
>> >> I wondered if there is some kind of guide to scrap hal.
>> >
>> > From my notes, having done it on  2  desktops machines +  1  netbook :
>> Nice .. many thanks but one question....
>>
>> >   To remove Hal : drop '-hal' flag, add 'udev' flag ;
>>
>> So no kind of hal flag in make.conf, or is `-hal' a typo that
>> should be `drop 'hal' flag?
>
>
> I wouldn't advise putting -hal in make.conf - that's globally and too many
> other things on the desktop still need it. Either
>
> a) disable it in /etc/make.conf and enable it in packages.use for stuff that
> needs it
> b) enable it in make.conf and disable it in packages.use for xorg-server
>
> I prefer b) as it's too easy to miss things using a).
>

I agree putting -hal is not a good idea unless you dare to break the
packages that need hal. But I think there is a third option here

c) take the default: if you dont put hal in make.conf or package.use,
packages will decide best for themselves..

Thu Oct 28 | 18:08:45 log # equery -C hasuse hal
[ Searching for USE flag hal in all categories among: ]
 * installed packages
[I--] [  ] media-sound/pulseaudio-0.9.21.1 (0)
[I--] [ -] app-emulation/wine-1.2 (0)
[I--] [  ] x11-base/xorg-server-1.7.7-r1 (0)
[I--] [  ] sys-fs/ntfs3g-2010.3.6 (0)
[I--] [ ~] kde-base/solid-4.5.2 (4.5)
[I--] [  ] media-libs/libgphoto2-2.4.9 (0)
[I--] [  ] x11-drivers/xf86-input-synaptics-1.2.1 (0)
[I--] [  ] xfce-base/exo-0.3.107 (0)
[I--] [  ] xfce-base/thunar-1.0.2 (0)
Thu Oct 28 | 18:08:56 log # grep ^hal /etc/make.conf
Thu Oct 28 | 18:08:58 log # grep ^hal /etc/portage/ -R
Thu Oct 28 | 18:09:00 log #

When kde gets rid of hal I might as well give up on all other packages
depend on it and totally get rid of the curst thing.

--
   Fatih

Re: [gentoo-user] scrapping hal

[Peter Humphrey]

On Thursday 28 October 2010 13:35:49 Alan McKinnon wrote:

> xorg-server 1.8 and 1.9 use mesa-7.8.2, and there's reports around
> that that version of mesa causes desktop slowdowns. mesa-7.7.1 as
> used by xorg- server-1.7 is reported to be fine

This box has been the most sluggish box I've ever seen for several 
months now. Mesa-7.7.1 was not fine here - or something else wasn't.
 
> Me, I'm undecided. I have a slow sluggish desktop, but it might be
> the nvidia drivers, mesa, X-server, kernel config, wrong elevator or
> even just the shitty IO scheduler design on desktops that the kernel
> devs are recently waking up to admitting to. Lots of stuff to change
> one at a time and see what results...

Puzzling, innit?

-- 
Rgds
Peter.          Linux Counter 5290, 1994-04-23.

Re: [gentoo-user] scrapping hal

[Dale]

Alan McKinnon wrote:
> Apparently, though unproven, at 16:36 on Thursday 28 October 2010, Dale did
> opine thusly:
>
>    
>> What's the old saying, if it's working, don't fix it.
>>      
> "What's the old saying, if it's working, don't fix it, until it's ancient, not
> supported and your box won't update world anymore so you are up the creek
> without a paddle and shit outta luck"
>
> There ya go, fixed that for ya Dale :-)
>
>    

Well, if I wanted to stay fairly ancient, I could have stayed with 
Mandrake.  They were pretty slow to release packages and even then they 
were way behind.  lol

That's one thing about Gentoo, you get new stuff pretty quick even if 
you run stable.  If you run unstable, you get things really quick, bugs 
and all.  ;-)

Speaking of ancient:

Apr 16  2009 /boot/bzImage-2.6.23-r8-8

I still got that old kernel in there.  I would be surprised if it would 
boot and work.  I bet udev would really have "issues" with that old 
thing.  I'm not running that tho.  I am actually up to 2.6.35-gentoo-r4 
so far.   See, I'm not completely ancient.  lol

Dale

:-)  :-)

Re: [gentoo-user] scrapping hal

[Paul Hartman]

On Thu, Oct 28, 2010 at 10:25 AM, Dale <rdalek1967@gmail.com> wrote:
> That's one thing about Gentoo, you get new stuff pretty quick even if you
> run stable.  If you run unstable, you get things really quick, bugs and all.
>  ;-)

Unstable is still pretty stable. If you really want to have fun start
to use some live ebuilds and rebuild new versions each day from
svn/git, and then deal with problems that occur because they expect
some specific git version of a library, so you use live ebuild of
that, which breaks other ebuilds which are made to work with the
stable release, and...   :)

Re: [gentoo-user] Re: scrapping hal

[Philip Webb]

101028 Alan McKinnon wrote:
> Harry Putnam did opine thusly:
>> Philip Webb <purslow@ca.inter.net> writes:
>>> From my notes, having done it on  2  desktops machines +  1  netbook :
>>>   To remove Hal : drop '-hal' flag, add 'udev' flag ;
>> So no kind of hal flag in make.conf
> or is `-hal' a typo that should be `drop 'hal' flag?

Yes, it's my own note to myself & reads wrongly for anyone else.
My 'make.conf' has

  USE="-* ... gtk2 handbook ... " (ordered alphabetically)

which means it does have "-hal", ie it drops 'hal'.

> I wouldn't advise putting -hal in make.conf - that's globally
> and too many other things on the desktop still need it.

Not on my machines.  I have used the "-* ... " approach for some years.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Re: scrapping hal

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Thu, 28 Oct 2010 18:11:42 +0300, Fatih Tümen wrote:

> I agree putting -hal is not a good idea unless you dare to break the
> packages that need hal. But I think there is a third option here

Packages that need hal won't have a hal use flag.


-- 
Neil Bothwick

Oxymoron: Reagan memoirs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] scrapping hal

[Alex Schuster]

Dale asks:

> They are probably already moved away from hal.  Everybody knows it is
> going and that is a bleeding edge version of xorg too.  I'm still on
> 1.7.*.

Me too.

> Which brings me to my next question.  How is xorg 1.9 working for ya?
> Any gotchas?  May try it here.

X starts, but crashes about a minute after logging into KDE4. I had 
similar experiences with 1.8.

I'm using the radeon drivers for my ATI Radeon HD 3200 card.

	Wonko

Re: [gentoo-user] Re: scrapping hal

[Fatih Tümen]

On Thu, Oct 28, 2010 at 21:21, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 28 Oct 2010 18:11:42 +0300, Fatih Tümen wrote:
>
>> I agree putting -hal is not a good idea unless you dare to break the
>> packages that need hal. But I think there is a third option here
>
> Packages that need hal won't have a hal use flag.
>

True, not every package that needs hal has hal use flag. I should have
made clear that my implication was those which have (optional)
dependency on hal && (thus) has hal flag. For packages that need hal
it doesn't matter whether you have -hal in your make.conf anyway, does
it?

--
   Fatih



>
> --
> Neil Bothwick
>
> Oxymoron: Reagan memoirs.
>

Re: [gentoo-user] Re: scrapping hal

[Alan McKinnon]

Apparently, though unproven, at 09:58 on Friday 29 October 2010, Fatih Tümen 
did opine thusly:

> On Thu, Oct 28, 2010 at 21:21, Neil Bothwick <neil@digimed.co.uk> wrote:
> > On Thu, 28 Oct 2010 18:11:42 +0300, Fatih Tümen wrote:
> >> I agree putting -hal is not a good idea unless you dare to break the
> >> packages that need hal. But I think there is a third option here
> > 
> > Packages that need hal won't have a hal use flag.
> 
> True, not every package that needs hal has hal use flag. I should have
> made clear that my implication was those which have (optional)
> dependency on hal && (thus) has hal flag. For packages that need hal
> it doesn't matter whether you have -hal in your make.conf anyway, does
> it?

Correct.

Something that requires hal will (should?) have it as an unconditional DEPEND.
USE is only for optional features.

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: scrapping hal

[Harry Putnam]

Paul Colquhoun <paulcol@andor.dropbear.id.au> writes:

> On Thu, 28 Oct 2010 14:54:51 Harry Putnam wrote:
>> Paul Hartman <paul.hartman+gentoo@gmail.com> writes:
>> > On Wed, Oct 27, 2010 at 4:06 PM, Harry Putnam <reader@newsguy.com> wrote:
>> >> I'm also guessing there is some kind of replacement that I need to
>> >> learn about if it effects my longtime reliance on xorg.conf to keep
>> >> using my huge desktops I like to use.  For yrs I've
>> >> used.
>> >> 
>> >>    Subsection "Display"
>> >>        Depth       24
>> >>        Modes       "1280x1024" #"1024x768" "800x600" "640x480"
>> >>        Virtual     2048 1536
>> >>        ViewPort    0 0
>> >>    EndSubsection
>> >> EndSection
>> >> 
>> >> in /etc/X11/xorg.conf
>> >> To get a 2048x1536 desktop to flop around on.
>> >> 
>> >> I've never seen or heard of a way to get that without using xorg.conf.
>> > 
>> > I think you would use xrandr to set it, or your desktop environment's
>> > GUI settings panel (or equivalent).
>> 
>> I may be using xrandr wrong but it doesn't do the trick used like
>> this:
>> 
>> I'm running an `emerge world' so didn't want to close down X so I used
>> Ctrl-alt F1 to leave X and then Ctrl-alt F2 to login on a different
>> virtual terminal.
>> 
>> Then commented out the `Virtual' line in xorg.conf:
>> 
>>     EndSubsection
>>     Subsection "Display"
>>         Depth       24
>>         Modes       "1280x1024" #"1024x768" "800x600" "640x480"
>> #        Virtual     2048 1536
>>         ViewPort    0 0
>>     EndSubsection
>> EndSection
>> 
>> 
>> Then startx on a different display.
>> 
>>   startx -- :1
>> 
>> Once X is up:
>> 
>>   xrandr <no args>
>>   shows 1280x1024 as being the highest resolution.
>> 
>> 
>>   xrandr -s 2048x1536 shows:
>> 
>>   Size  2048x1536 not found in available modes
>> 
>> The xfce display setting tool also shows 1280 as the highest possible
>> setting.
>> 
>> I've asked before where else this might be set... in more than 1
>> forum.  I think you may find its not all that easy to set a Resolution
>> way higher than your card supports.
>
>
> Did you look at the man page for xrandr?

Yes, but failed to notice that long complex command

I saw -s <size> and thought I'd found the right switch.

> I think you need the "--fb" & "--panning" options. There is even an example 
> towards the end of the man page.

I guess you mean this monstrosity?

       Have  one  small 1280x800 LVDS screen showing a small version of a huge
       3200x2000 desktop, and have a big VGA screen display the surrounding of
       the mouse at normal size.
              xrandr --fb 3200x2000 --output LVDS --scale 2.5x2.5 --output VGA
              --pos 0x0 --panning 3200x2000+0+0/3200x2000+0+0/64/64/64/64


Thanks... I'll try that